consomme: add dns resolver #2633
Conversation
|
This PR modifies files containing For more on why we check whole files, instead of just diffs, check out the Rustonomicon |
There was a problem hiding this comment.
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 |
| let payload_offset = ETHERNET_HEADER_LEN + IPV4_HEADER_LEN + UDP_HEADER_LEN; | ||
| let required_size = payload_offset + response.response_data.len(); | ||
|
|
||
| if required_size > buffer.len() { | ||
| return Err(DropReason::SendBufferFull); | ||
| } | ||
|
|
||
| buffer[payload_offset..required_size].copy_from_slice(&response.response_data); |
There was a problem hiding this comment.
The DNS response data length is not validated before copying it into the buffer. While the buffer size check at line 390-392 prevents buffer overflow, a malicious or buggy DNS resolver could return a response larger than the buffer, causing this function to fail with DropReason::SendBufferFull. Consider adding additional validation or logging for abnormally large DNS responses to aid debugging and detect potential issues with the DNS backends.
1 participant
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:
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.