starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #1507] Resolution delay for IPv6 lookups when using Happy Eyeballs V2 #688

New issue

Open

opened 2026-03-15 23:48:30 +03:00 by kerem · 11 comments

kerem commented

2026-03-15 23:48:30 +03:00

Owner

Originally created by @saiintbrisson on GitHub (Jun 8, 2021).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1507

Hi! I'm currently studying DNS lookups and I got myself wondering if the resolver crate has support for the Happy Eyeballs Resolution delay:

The algorithm proceeds as follows: if a positive AAAA response (a
response with at least one valid AAAA record) is received first, the
first IPv6 connection attempt is immediately started. If a positive
A response is received first due to reordering, the client SHOULD
wait a short time for the AAAA response to ensure that preference is
given to IPv6 (it is common for the AAAA response to follow the A
response by a few milliseconds). This delay will be referred to as
the "Resolution Delay". The recommended value for the Resolution
Delay is 50 milliseconds. If a positive AAAA response is received

I noticed that the lookup_ip method does something along those lines, but I couldn't find any mention of delays. Am I missing something, or does this project have any intentions of implementing it?

Originally created by @saiintbrisson on GitHub (Jun 8, 2021). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1507 Hi! I'm currently studying DNS lookups and I got myself wondering if the resolver crate has support for the Happy Eyeballs Resolution delay: > The algorithm proceeds as follows: if a positive AAAA response (a response with at least one valid AAAA record) is received first, the first IPv6 connection attempt is immediately started. If a positive A response is received first due to reordering, the client SHOULD wait a short time for the AAAA response to ensure that preference is given to IPv6 (it is common for the AAAA response to follow the A response by a few milliseconds). This delay will be referred to as the "Resolution Delay". The recommended value for the Resolution Delay is 50 milliseconds. If a positive AAAA response is received I noticed that the lookup_ip method does something along those lines, but I couldn't find any mention of delays. Am I missing something, or does this project have any intentions of implementing it?

kerem added the

crate:resolver

question

labels

2026-03-15 23:48:30 +03:00

kerem commented

2026-03-15 23:48:41 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 8, 2021):

https://docs.rs/trust-dns-resolver/0.20.3/trust_dns_resolver/config/enum.LookupIpStrategy.html#variant.Ipv6thenIpv4

Is there a reason you want/need the delay? right now, the ipv6 lookup needs to fail then the ipv4 lookup will be attempted.

@bluejekyll commented on GitHub (Jun 8, 2021): https://docs.rs/trust-dns-resolver/0.20.3/trust_dns_resolver/config/enum.LookupIpStrategy.html#variant.Ipv6thenIpv4 Is there a reason you want/need the delay? right now, the ipv6 lookup needs to fail then the ipv4 lookup will be attempted.

kerem commented

2026-03-15 23:48:46 +03:00

Author

Owner

@djc commented on GitHub (Jun 8, 2021):

I think the OP is suggesting that we should maybe have a new strategy that issues A and AAAA queries in parallel but will return IPv6 even if IPv6 is returned within a defined delay (default to 50ms) after IPv4. This is slightly different than either of the existing Ipv4AndIpv6 or Ipv6ThenIpv4 strategies.

(This could certainly be implemented on the application-side, but it might be nice to provide as a default option. I think hyper also tries to follow the Happy Eyeballs recommendations.)

@djc commented on GitHub (Jun 8, 2021): I think the OP is suggesting that we should maybe have a new strategy that issues A and AAAA queries in parallel but will return IPv6 even if IPv6 is returned within a defined delay (default to 50ms) after IPv4. This is slightly different than either of the existing `Ipv4AndIpv6` or `Ipv6ThenIpv4` strategies. (This could certainly be implemented on the application-side, but it might be nice to provide as a default option. I think hyper also tries to follow the Happy Eyeballs recommendations.)

kerem commented

2026-03-15 23:48:51 +03:00

Author

Owner

@saiintbrisson commented on GitHub (Jun 8, 2021):

Is there a reason you want/need the delay?

There isn't a specific reason for now, but I think this could be a nice thing to have as default, as @djc said. Ipv4AndIpv6 is the most similar alternative, it's only lacking the delay option, maybe there could be a new strategy, or a config entry like hyper does (https://github.com/hyperium/hyper/blob/master/src/client/connect/http.rs#L74). If this sounds interesting I'd be willing to create a PR implementing it.

@saiintbrisson commented on GitHub (Jun 8, 2021): > Is there a reason you want/need the delay? There isn't a specific reason for now, but I think this could be a nice thing to have as default, as @djc said. `Ipv4AndIpv6` is the most similar alternative, it's only lacking the delay option, maybe there could be a new strategy, or a config entry like hyper does (https://github.com/hyperium/hyper/blob/master/src/client/connect/http.rs#L74). If this sounds interesting I'd be willing to create a PR implementing it.

kerem commented

2026-03-15 23:48:57 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 8, 2021):

Is the issue that some resolves don't respond to the ipv6 request?

As is, the lookup_ip with Ipv4AndIpv6 will return both (waiting for positive or negative response), and Ipv6ThenIpv4 will first wait for the Ipv6 request to fail. I guess I don't fully grok the ipv6 timeout as explained in the RFC. We could shorten the timeout on one or the other, but my assumption is that if either returns a response, we'd get a positive/negative response for the other (not a timeout), or both would timeout (because the resolver can't be contacted)? Am I missing something about resolvers that don't support AAAA record types and silently ignore them or something (this would be the only reason I can imagine wanting the behavior in the RFC)?

I'm not against fixing this to work as expressed in the RFC, but I guess I don't see how it practically matters... And, yes! If you'd like to work on a PR for this, that would absolutely be welcomed.

@bluejekyll commented on GitHub (Jun 8, 2021): Is the issue that some resolves don't respond to the ipv6 request? As is, the lookup_ip with Ipv4AndIpv6 will return both (waiting for positive or negative response), and Ipv6ThenIpv4 will first wait for the Ipv6 request to fail. I guess I don't fully grok the ipv6 timeout as explained in the RFC. We could shorten the timeout on one or the other, but my assumption is that if either returns a response, we'd get a positive/negative response for the other (not a timeout), or both would timeout (because the resolver can't be contacted)? Am I missing something about resolvers that don't support AAAA record types and silently ignore them or something (this would be the only reason I can imagine wanting the behavior in the RFC)? I'm not against fixing this to work as expressed in the RFC, but I guess I don't see how it practically matters... And, yes! If you'd like to work on a PR for this, that would absolutely be welcomed.

kerem commented

2026-03-15 23:49:02 +03:00

Author

Owner

@djc commented on GitHub (Jun 9, 2021):

The explicit goal for Happy Eyeballs is to prioritize IPv6:

The Happy Eyeballs algorithm of racing connections to resolved addresses has several stages to avoid delays to the user whenever possible, while preferring the use of IPv6.

It seems the issue is that resolvers will deliver the A result more quickly than the AAAA result, so the user wants to prioritize IPv6, some additional timeout is required.

@djc commented on GitHub (Jun 9, 2021): The explicit goal for Happy Eyeballs is to prioritize IPv6: > The Happy Eyeballs algorithm of racing connections to resolved addresses has several stages to avoid delays to the user whenever possible, while preferring the use of IPv6. It seems the issue is that resolvers will deliver the A result more quickly than the AAAA result, so the user wants to prioritize IPv6, some additional timeout is required.

kerem commented

2026-03-15 23:49:07 +03:00

Author

Owner

@saiintbrisson commented on GitHub (Jun 10, 2021):

As stated earlier, the goal is to prioritize IPv6, AAAA queries are usually a bit slower. I'll try implementing it this weekend!

@saiintbrisson commented on GitHub (Jun 10, 2021): As stated earlier, the goal is to prioritize IPv6, AAAA queries are usually a bit slower. I'll try implementing it this weekend!

kerem commented

2026-03-15 23:49:12 +03:00

Author

Owner

@link2xt commented on GitHub (Feb 15, 2024):

It would be nice to at least switch the default to https://docs.rs/trust-dns-resolver/latest/trust_dns_resolver/config/enum.LookupIpStrategy.html#variant.Ipv4AndIpv6
EDIT: I see there is a reason why it is not used by default: https://github.com/hickory-dns/hickory-dns/pull/1332#issuecomment-751928998

Current default strategy prefers IPv4 in a way that IPv6 is almost never used:
https://github.com/n0-computer/iroh/issues/2006

@link2xt commented on GitHub (Feb 15, 2024): It would be nice to at least switch the default to https://docs.rs/trust-dns-resolver/latest/trust_dns_resolver/config/enum.LookupIpStrategy.html#variant.Ipv4AndIpv6 EDIT: I see there is a reason why it is not used by default: https://github.com/hickory-dns/hickory-dns/pull/1332#issuecomment-751928998 Current default strategy prefers IPv4 in a way that IPv6 is almost never used: https://github.com/n0-computer/iroh/issues/2006

kerem commented

2026-03-15 23:49:17 +03:00

Author

Owner

@djc commented on GitHub (Feb 15, 2024):

I feel like all of the existing strategies are not great, and we maybe need a new one? Along the lines of:

Send IPv6 request
Send IPv4 request (without waiting for IPv6 result)
Use the protocol that gets a response first

@djc commented on GitHub (Feb 15, 2024): I feel like all of the existing strategies are not great, and we maybe need a new one? Along the lines of: - Send IPv6 request - Send IPv4 request (without waiting for IPv6 result) - Use the protocol that gets a response first

kerem commented

2026-03-15 23:49:22 +03:00

Author

Owner

@FalkWoldmann commented on GitHub (Sep 2, 2025):

Hi @djc, sorry to bump this, but as seen in https://github.com/hyperium/hyper-util/pull/200 and in https://github.com/seanmonstar/reqwest/issues/2679, using reqwest with the hickory-dns, the client returns an IPv4 address even if an IPv6 address is available. Considering that @seanmonstar mentioned in his blog entry the possibility of making hickory-dns the default, it would be great to have this addressed. I could imagine other people also being surprised by the current behavior.

@FalkWoldmann commented on GitHub (Sep 2, 2025): Hi @djc, sorry to bump this, but as seen in https://github.com/hyperium/hyper-util/pull/200 and in https://github.com/seanmonstar/reqwest/issues/2679, using `reqwest` with the `hickory-dns`, the client returns an IPv4 address even if an IPv6 address is available. Considering that @seanmonstar mentioned in his [blog entry](https://seanmonstar.com/blog/modular-reqwest/) the possibility of making hickory-dns the default, it would be great to have this addressed. I could imagine other people also being surprised by the current behavior.

kerem commented

2026-03-15 23:49:27 +03:00

Author

Owner

@djc commented on GitHub (Sep 2, 2025):

Wrote something up in #3247. If anyone wants to help with testing (ideally writing some unit tests), that would be great!

@djc commented on GitHub (Sep 2, 2025): Wrote something up in #3247. If anyone wants to help with testing (ideally writing some unit tests), that would be great!

kerem commented

2026-03-15 23:49:32 +03:00

Author

Owner

@saiintbrisson commented on GitHub (Sep 3, 2025):

As stated earlier, the goal is to prioritize IPv6, AAAA queries are usually a bit slower. I'll try implementing it this weekend!

It was a very long weekend 😅 . Thanks for giving this a shot @djc, much appreciated.

@saiintbrisson commented on GitHub (Sep 3, 2025): > As stated earlier, the goal is to prioritize IPv6, AAAA queries are usually a bit slower. I'll try implementing it this weekend! It was a very long weekend 😅 . Thanks for giving this a shot @djc, much appreciated.

kerem referenced this issue

2026-03-16 02:15:42 +03:00

[PR #688] [MERGED] Add support for ECDSA signing with ring #1606