consomme: add dns resolver

[damanm24]

This PR changes the manner in which DNS is done in consomme and aligns the implementation closer with what is implemented in WSL.

The current approach to DNS is: the guest uses DHCP to communicate with the host, and the host will pass it's current DNS settings back to the guest (obtained from either /etc/resolv.conf (on linux hosts) and or via the GetAdatpersAddresses Win32 API call (on Windows hosts)). Thus, all DNS requests made from the guest are addressed directly to the same DNS servers that are configured on the host (obviously they are still proxied through consomme).

The new approach is to pass Consomme's self-assigned ip address to the guest via DHCP and resolve the DNS requests by using syscalls available on the host:

• On windows: DnsQueryRaw
• On Linux/MacOs: res_send

This is more aligned to how WSL handles DNS today: https://github.com/microsoft/WSL/blob/fdfe1eb8439370c9eb6780467abc1e3f08f90eb1/src/windows/service/exe/DnsResolver.cpp#L9

There is one major follow-up item that will have to be addressed:
DnsQueryRaw is only available on newer releases of Windows 11, so in the event that this function is not available in the dnsapi.dll currently on the system, we will have to fallback to using DnsQueryEx.

To keep the scope of this already large PR manageable, this will be handled in a follow-up PR.

[github-actions]

⚠️ Unsafe Code Detected

This PR modifies files containing unsafe Rust code. Extra scrutiny is required during review.

For more on why we check whole files, instead of just diffs, check out the Rustonomicon

[Copilot]

Pull request overview

This PR implements a new DNS resolution approach for consomme, changing from direct host DNS passthrough to self-hosted resolution using OS syscalls. The implementation uses Windows' DnsQueryRaw API and Unix's res_send libc function, aligning with WSL's DNS handling approach.

Key changes:

• New DNS resolver infrastructure with platform-specific backends (Windows: DnsQueryRaw, Unix: res_send)
• Integration of DNS handling into UDP packet processing flow
• Major dependency update: smoltcp 0.8 → 0.12 with associated API adaptations
• DHCP server now advertises consomme's gateway IP as DNS server when resolver is available

Reviewed changes

Copilot reviewed 13 out of 14 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
Cargo.toml / Cargo.lock	Added heapless, tracelimit dependencies; upgraded smoltcp to 0.12.0 with new transitive dependencies
consomme/build.rs	New build script to link resolver library on Unix platforms
consomme/Cargo.toml	Added dependencies and Windows API features for DNS implementation
dns/mod.rs	Core DNS resolver interface, response queuing, and SERVFAIL response generation
dns/dns_resolver_windows.rs	Windows DNS backend using DnsQueryRaw with async callback handling
dns/dns_resolver_unix.rs	Unix DNS backend using res_send with dedicated worker thread
dns/delay_load.rs	Windows DLL delay-loading for runtime DNS API availability detection
lib.rs	DNS resolver initialization and integration into Consomme instance
udp.rs	DNS request handling, response sending, and refactored UDP packet building
tcp.rs	API updates for smoltcp 0.12 (protocol→next_header, timestamp field, type conversions)
dhcp.rs	Updated for smoltcp 0.12 DHCP API changes (heapless::Vec for DNS servers, new fields)
icmp.rs	Type conversion updates for Ipv4Address changes
dns_unix.rs	Type conversion update in nameserver parsing

[github-actions]

At least one Petri test failed.

[jstarks]

see comments

[Copilot]

Pull request overview

Copilot reviewed 14 out of 15 changed files in this pull request and generated 5 comments.

[github-actions]

At least one Petri test failed.

[jstarks]

I'd probably use Slab instead of HashMap<u64.

[jstarks]

We want to make sure we're always pushing a response. I think this would be easier to ensure if you structured the code so that each code path had to provide a value, rather than relying on each code path to perform a specific action. E.g.:

let response = {
    if query_results.is_null() { // probably this case goes away, see my other comment
        tracelimit::warn_ratelimited!("null results");
        None
    } else if foo && bar {
        DnsResponse { ... } 
    } else if x {
        tracelimit::warn_ratelimited!("blah blah");
        None
    }
};
match response {
    Some(response) => context.request.accessor.push(response),
    None => push_servfail_response(...),
}

You could also consider taking that code and putting it in another function so that you can use control flow to keep the nesting from getting too deep. E.g., you can return None or use ? in some cases. You could even make an error type so that you could get down to a single trace statement for all the error cases.

[jstarks]

I suspect that in the fullness of time we'll want to instead implement our own resolver, using OS-specific mechanisms to get the nameserver to use. This is what Chrome does, I think.

[jstarks]

Oof. This is worrysome. How do we make sure this is big enough?

[damanm24]

Is it worth using bindgen here to generate the res_state type defined in resolv.h?