You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ResolveUDPAddr is a misleading function anyway, since it returns a single result. A typical DNS response will contain multiple A and AAAA records.
After discussing this on the QUIC Slack, I believe this is what a "correct" implementation would look like:
We need to do DNS resolution ourselves (using a net.Resolver).
If we receive both A and AAAA, we should start dialing IPv6 first, and try IPv4 shortly after if that doesn't work. This is the Happy Eyeballs logic described in RFC 8305.
This results in two loops, dialing A and AAAA addresses in parallel. If a connection timeout times out, we should start dialing the next address.
Unfortunately, this is some significant complexity. DialAddr would not be a very thin wrapper around Dial any more. However, most users of quic-go probably want to connect to a domain, and not only an IP address, so it seems like this logic either belongs into quic-go or into a wrapper around quic-go, otherwise it would have to be reimplemented again and again.
This results in interesting interactions between the dial context timeout and the handshake timeout. Specifically, the dial context timeout needs to be larger than the handshake timeout for us to be able to proceed to the second A / AAAA record if the first one fails. As the context deadline is set by the deadline, there's not a lot we can do about this, other than being very clear how the logic works.
Following up on #3755 (comment), I believe our
DialAddrmethod is not doing the right thing:ResolveUDPAddr, which prefers IPv4 over IPv6 (we should do the opposite!). See http3: client always prefers IPv4 #3755 for more details.ResolveUDPAddris a misleading function anyway, since it returns a single result. A typical DNS response will contain multiple A and AAAA records.After discussing this on the QUIC Slack, I believe this is what a "correct" implementation would look like:
net.Resolver).Unfortunately, this is some significant complexity.
DialAddrwould not be a very thin wrapper aroundDialany more. However, most users of quic-go probably want to connect to a domain, and not only an IP address, so it seems like this logic either belongs into quic-go or into a wrapper around quic-go, otherwise it would have to be reimplemented again and again.This results in interesting interactions between the dial context timeout and the handshake timeout. Specifically, the dial context timeout needs to be larger than the handshake timeout for us to be able to proceed to the second A / AAAA record if the first one fails. As the context deadline is set by the deadline, there's not a lot we can do about this, other than being very clear how the logic works.