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 #300] change default LookupIpStrategy from `Ipv4AndIpv6` to `Ipv4thenIpv6`? #434

New issue

Closed

opened 2026-03-15 22:27:54 +03:00 by kerem · 10 comments

kerem commented

2026-03-15 22:27:54 +03:00

Owner

Originally created by @cssivision on GitHub (Nov 26, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/300

ipv6 is not well supported now, Ipv4AndIpv6 Query for A and AAAA in parallel, the situation is that if the website you visited support ipv6, but your network do not support ipv6, you will get a Network Unreachable error.

Originally created by @cssivision on GitHub (Nov 26, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/300 ipv6 is not well supported now, `Ipv4AndIpv6` Query for A and AAAA in parallel, the situation is that if the website you visited support ipv6, but your network do not support ipv6, you will get a `Network Unreachable` error.

kerem

2026-03-15 22:27:54 +03:00

closed this issue
added the
crate:resolver
label

kerem commented

2026-03-15 22:28:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 26, 2017):

Can you describe your toolchain as your using it? That is, is this something that you could override locally? There are a few options for that.

The reason I picked IPv4AndIPv6 as the default was to make sure that there wasn't a hit in lookup speed for IPv4ThenIpv6. I'm open to this, but would love additional input from other users.

@bluejekyll commented on GitHub (Nov 26, 2017): Can you describe your toolchain as your using it? That is, is this something that you could override locally? There are a few options for that. The reason I picked `IPv4AndIPv6` as the default was to make sure that there wasn't a hit in lookup speed for `IPv4ThenIpv6`. I'm open to this, but would love additional input from other users.

kerem commented

2026-03-15 22:28:15 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 26, 2017):

i use default config by function from_system_conf, and my network only support ipv4, when i query dns for www.google.com sometimes it return ipv6 address, and my application failed.

the options field of ResolverFuture struct is not pub, and there is no way for me to change this ip_strategy if i want to use system default config.

@cssivision commented on GitHub (Nov 26, 2017): i use default config by function `from_system_conf`, and my network only support ipv4, when i query dns for `www.google.com` sometimes it return ipv6 address, and my application failed. the `options` field of `ResolverFuture` struct is not `pub`, and there is no way for me to change this `ip_strategy` if i want to use system default config.

kerem commented

2026-03-15 22:28:20 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 26, 2017):

maybe we can make this options field pub?

@cssivision commented on GitHub (Nov 26, 2017): maybe we can make this `options` field `pub`?

kerem commented

2026-03-15 22:28:25 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 26, 2017):

I'd prefer not making that field pub I honestly don't know what would happen if you change the config after initialization, and don't know if I want to be restricted by that if we do allow it.

Based on your use case, I wonder if we should change this default, possibly by platform. What system are you on? I do think this this matches the way glibc performs lookups on linux, from the resolv.conf man pages:

... By default, glibc
performs IPv4 and IPv6 lookups in parallel since
version 2.9. ...

Example to override system conf:

let (mut config, mut options) = system_conf::read_system_conf()?;
options.... = ...;
config.... = ...;
let resolver = ResolverFuture::new(config, options, reactor))?;

@bluejekyll commented on GitHub (Nov 26, 2017): I'd prefer not making that field `pub` I honestly don't know what would happen if you change the config after initialization, and don't know if I want to be restricted by that if we do allow it. Based on your use case, I wonder if we should change this default, possibly by platform. What system are you on? I do think this this matches the way glibc performs lookups on linux, from the resolv.conf man pages: ```text ... By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9. ... ``` ---- Example to override system conf: ```rust let (mut config, mut options) = system_conf::read_system_conf()?; options.... = ...; config.... = ...; let resolver = ResolverFuture::new(config, options, reactor))?; ```

kerem commented

2026-03-15 22:28:30 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 26, 2017):

according to RFC 6724 it seems that we should respect the order provided by getaddrinfo(3). It is already configured to use IPv6 first if both sides have native IPv6, but use IPv4 first if both sides are tunnelling. See RFC 6724 (the new version of RFC 3484), which is implemented in most libc.

@cssivision commented on GitHub (Nov 26, 2017): according to `RFC 6724` it seems that we should respect the order provided by getaddrinfo(3). It is already configured to use IPv6 first if both sides have native IPv6, but use IPv4 first if both sides are tunnelling. See RFC 6724 (the new version of RFC 3484), which is implemented in most libc.

kerem commented

2026-03-15 22:28:35 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 26, 2017):

https://tools.ietf.org/html/rfc6724 has a lot of details that are still unimplemented by the Resolver...

Maybe we should open a separate issue, or rename this one, to instead be an enhancement to properly implement that RFC? It will take some work, as I don't think the Resolver currently supports options around a lot of the features being dictated in that yet.

@bluejekyll commented on GitHub (Nov 26, 2017): https://tools.ietf.org/html/rfc6724 has a lot of details that are still unimplemented by the Resolver... Maybe we should open a separate issue, or rename this one, to instead be an enhancement to properly implement that RFC? It will take some work, as I don't think the Resolver currently supports options around a lot of the features being dictated in that yet.

kerem commented

2026-03-15 22:28:40 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 26, 2017):

currently, resolver picks IPv4/IPv6 at random, i think we should have a determined operations, otherwise the users can't make up its mind.

now, i write code below to fix the problems.

if let Some(addr) = res.iter().filter(|addr| addr.is_ipv4()).next() {
            future::ok(addr)
        } else {
            future::err(io::Error::new(
                io::ErrorKind::Other,
                "resolve fail".to_string(),
            ))
}

in my opinion, before this problem is solved, make Ipv4thenIpv6 as a default LookupIpStrategy is a good solution.

@cssivision commented on GitHub (Nov 26, 2017): currently, resolver picks IPv4/IPv6 at random, i think we should have a determined operations, otherwise the users can't make up its mind. now, i write code below to fix the problems. ```rust if let Some(addr) = res.iter().filter(|addr| addr.is_ipv4()).next() { future::ok(addr) } else { future::err(io::Error::new( io::ErrorKind::Other, "resolve fail".to_string(), )) } ``` in my opinion, before this problem is solved, make `Ipv4thenIpv6` as a default `LookupIpStrategy` is a good solution.

kerem commented

2026-03-15 22:28:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 26, 2017):

fair enough. Would you want to submit a PR?

@bluejekyll commented on GitHub (Nov 26, 2017): fair enough. Would you want to submit a PR?

kerem commented

2026-03-15 22:28:51 +03:00

Author

Owner

@cssivision commented on GitHub (Nov 26, 2017):