Filter DNS Results by Interface Type #111
Conversation
sgodin
commented
Nov 6, 2025
sgodin
commented
- The default bind address is [::]:0 (v6)
- If binding to V4 address, then filter DNS responses to v4 results only
- If binding to V6 address and on linux, then behavior is unchanged (linux is dual-stack and can send to IPv4 destinations on a v6 socket)
- If binding to V6 address and non-linux, then filter DNS responses to v6 results only
- The default bind address is [::]:0 (v6) - If binding to V4 address, then filter DNS responses to v4 results only - If binding to V6 address and on linux, then behavior is unchanged (linux is dual-stack and can send to IPv4 destinations on a v6 socket) - If binding to V6 address and non-linux, then filter DNS responses to v6 results only
There was a problem hiding this comment.
Pull Request Overview
This PR enhances DNS address selection logic in the QUIC client connection code to handle IPv4/IPv6 compatibility based on the local socket type and operating system.
Key Changes:
- Collects all DNS lookup results instead of taking only the first result
- Implements OS-aware address selection: IPv4-only sockets prefer IPv4 addresses, Linux IPv6 sockets use the first DNS result (dual-stack), and non-Linux IPv6 sockets prefer IPv6 addresses
- Adds fallback logic to use the first available address if the preferred selection fails
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } else if cfg!(target_os = "linux") { | ||
| // If IPv6 and running on Linux (dual-stack), use top DNS result | ||
| addrs.first().cloned() |
There was a problem hiding this comment.
The logic for Linux dual-stack sockets (line 325) uses the "top DNS result" without any preference for IPv4 or IPv6. While this may work, it's unclear why Linux is treated differently. The comment mentions "dual-stack" which suggests IPv6 sockets on Linux can handle both IPv4 and IPv6, but the code doesn't verify this assumption. If the intent is to handle IPv4-mapped IPv6 addresses on Linux, this should be documented more clearly, or the logic should explicitly check for dual-stack capability rather than assuming it based on OS.
There was a problem hiding this comment.
This is a reasonable point, I'd like to leave this as a future todo, as the previous logic is still improved here, and not made worse.
- log out all DNS results to assist in troubleshooting - move client connection logs to debug level
1 participant
