starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2273] Resolver takes a long time to resolve NXDOMAIN #945

New issue

Open

opened 2026-03-16 01:03:09 +03:00 by kerem · 8 comments

kerem commented

2026-03-16 01:03:09 +03:00

Owner

Originally created by @mhils on GitHub (Jul 2, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2273

Describe the bug

~~When hickory-resolver is configured with more than two nameservers and one of the first two is not reachable, DNS resolution takes five seconds for NXDOMAIN responses.~~

Edit: see https://github.com/hickory-dns/hickory-dns/issues/2273#issuecomment-2205877684

To Reproduce

#!/usr/bin/env cargo +nightly -Zscript
---
[dependencies]
hickory-resolver = { git = "https://github.com/hickory-dns/hickory-dns.git" }
---


use std::net::*;
use std::str::FromStr;
use hickory_resolver::Resolver;
use hickory_resolver::config::*;

fn main() {
    dbg!(hickory_resolver::version());
    let mut config = ResolverConfig::new();
    config.add_name_server(NameServerConfig::new(SocketAddr::from_str("1.1.1.1:53").unwrap(), Protocol::Udp));
    config.add_name_server(NameServerConfig::new(SocketAddr::from_str("8.8.8.8:54").unwrap(), Protocol::Udp));  // invalid port
    config.add_name_server(NameServerConfig::new(SocketAddr::from_str("9.9.9.9:55").unwrap(), Protocol::Udp));  // invalid port
    
    let resolver = Resolver::new(config, ResolverOpts::default()).unwrap();

    let start = std::time::Instant::now();
    dbg!(resolver.lookup_ip("nxdomain.example.com").unwrap_err());
    let stop = std::time::Instant::now();
    dbg!(stop - start);
}

Output:

> ./repro.rs
[/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:14:5] hickory_resolver::version() = "0.25.0-alpha.1"
[/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:23:5] resolver.lookup_ip("nxdomain.example.com").unwrap_err() = ResolveError {
    kind: Proto(
        ProtoError {
            kind: NoRecordsFound { ... },
    ),
}
[/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:25:5] stop - start = 5.019177416s

Removing the third nameserver reduces the resolution time to normal levels (13ms on my system).

Expected behavior
Faster resolution. :)

System:

OS: macOS
Architecture: arm64
Version: 14.5
rustc version: 1.79

Version:
Crate: resolver
Version: v0.24.1 and HEAD

Additional context
Thank you for your fantastic work on hickory! 🍰 ❤️

Originally created by @mhils on GitHub (Jul 2, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2273 **Describe the bug** <s>When hickory-resolver is configured with more than two nameservers and one of the first two is not reachable, DNS resolution takes five seconds for NXDOMAIN responses.</s> Edit: see https://github.com/hickory-dns/hickory-dns/issues/2273#issuecomment-2205877684 **To Reproduce** ```rust #!/usr/bin/env cargo +nightly -Zscript --- [dependencies] hickory-resolver = { git = "https://github.com/hickory-dns/hickory-dns.git" } --- use std::net::*; use std::str::FromStr; use hickory_resolver::Resolver; use hickory_resolver::config::*; fn main() { dbg!(hickory_resolver::version()); let mut config = ResolverConfig::new(); config.add_name_server(NameServerConfig::new(SocketAddr::from_str("1.1.1.1:53").unwrap(), Protocol::Udp)); config.add_name_server(NameServerConfig::new(SocketAddr::from_str("8.8.8.8:54").unwrap(), Protocol::Udp)); // invalid port config.add_name_server(NameServerConfig::new(SocketAddr::from_str("9.9.9.9:55").unwrap(), Protocol::Udp)); // invalid port let resolver = Resolver::new(config, ResolverOpts::default()).unwrap(); let start = std::time::Instant::now(); dbg!(resolver.lookup_ip("nxdomain.example.com").unwrap_err()); let stop = std::time::Instant::now(); dbg!(stop - start); } ``` Output: ``` > ./repro.rs [/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:14:5] hickory_resolver::version() = "0.25.0-alpha.1" [/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:23:5] resolver.lookup_ip("nxdomain.example.com").unwrap_err() = ResolveError { kind: Proto( ProtoError { kind: NoRecordsFound { ... }, ), } [/Users/mhils/.cargo/target/a4/4553f572871dfe/repro.rs:25:5] stop - start = 5.019177416s ``` Removing the third nameserver reduces the resolution time to normal levels (13ms on my system). **Expected behavior** Faster resolution. :) **System:** - OS: macOS - Architecture: arm64 - Version: 14.5 - rustc version: 1.79 **Version:** Crate: resolver Version: v0.24.1 and HEAD **Additional context** Thank you for your fantastic work on hickory! 🍰 ❤️

kerem commented

2026-03-16 01:03:15 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jul 3, 2024):

It sounds like the third nameserver is not responding. Is that right?

@bluejekyll commented on GitHub (Jul 3, 2024): It sounds like the third nameserver is not responding. Is that right?

kerem commented

2026-03-16 01:03:20 +03:00

Author

Owner

@mhils commented on GitHub (Jul 3, 2024):

That is correct.

Scenario A: Two nameservers configured, only the first one is responding: Immediate response.
Scenario B: Three nameservers configured, only the first one is responding: 5s timeout.

Here's what WireShark shows for Scenario B. As in the code above, 8.8.8.8 and 9.9.9.9 are unreachable (wrong port):

dns.pcapng.zip

@mhils commented on GitHub (Jul 3, 2024): That is correct. **Scenario A:** Two nameservers configured, only the first one is responding: Immediate response. **Scenario B:** Three nameservers configured, only the first one is responding: 5s timeout. Here's what WireShark shows for Scenario B. As in the code above, 8.8.8.8 and 9.9.9.9 are unreachable (wrong port): <img width="1167" alt="image" src="https://github.com/hickory-dns/hickory-dns/assets/1019198/abf91c48-cfdd-4668-af5e-75278f0e6b48"> [dns.pcapng.zip](https://github.com/user-attachments/files/16080924/dns.pcapng.zip)

kerem commented

2026-03-16 01:03:25 +03:00

Author

Owner

@djc commented on GitHub (Jul 3, 2024):

What is your expected behavior here? If you configure a number of nameservers, wouldn't you expect all of them would be tried? Is there a threshold particular to two nameservers? What happens when you have your "third" (failing to respond) nameserver second (omitting the second nameserver)?

@djc commented on GitHub (Jul 3, 2024): What is your expected behavior here? If you configure a number of nameservers, wouldn't you expect all of them would be tried? Is there a threshold particular to two nameservers? What happens when you have your "third" (failing to respond) nameserver second (omitting the second nameserver)?

kerem commented

2026-03-16 01:03:30 +03:00

Author

Owner

@mhils commented on GitHub (Jul 3, 2024):

Thank you two - I bamboozled myself when turning this into a MRE. 🙈 My non-minified code only had a single non-responsive DNS server. But I was also using read_system_conf(), and read_system_conf() sets trust_negative_responses = false, which in turn makes the resolver wait...

Is there a reason why trust_negative_responses is set to false for system configurations? Is that working around some known bugs? The 5s timeout was certainly unexpected for me seeing an immediate NXDOMAIN response in Wireshark.

@mhils commented on GitHub (Jul 3, 2024): Thank you two - I bamboozled myself when turning this into a MRE. 🙈 My non-minified code only had a single non-responsive DNS server. But I was also using `read_system_conf()`, and `read_system_conf()` sets `trust_negative_responses = false`, which in turn makes the resolver wait... Is there a reason why `trust_negative_responses` is set to `false` for system configurations? Is that working around some known bugs? The 5s timeout was certainly unexpected for me seeing an immediate NXDOMAIN response in Wireshark.

kerem commented

2026-03-16 01:03:35 +03:00

Author

Owner

@djc commented on GitHub (Jul 3, 2024):

See #1861 for discussion -- I forget the deep context, maybe @bluejekyll remembers.

@djc commented on GitHub (Jul 3, 2024): See #1861 for discussion -- I forget the deep context, maybe @bluejekyll remembers.

kerem commented

2026-03-16 01:03:40 +03:00

Author

Owner

@mhils commented on GitHub (Jul 3, 2024):

Thanks @djc!

Doing some archeology here, #1212 moved the trust bit from ResolverOpts to NameServerConfig. This is how trust_nx_responses: false was introduced to system_conf. #1861 then renames it. I can't find any artifacts describing why NXDOMAIN is treated as untrustworthy by default though. :)

@mhils commented on GitHub (Jul 3, 2024): Thanks @djc! Doing some archeology here, #1212 moved the trust bit from ResolverOpts to NameServerConfig. This is how `trust_nx_responses: false` was introduced to system_conf. #1861 then renames it. I can't find any artifacts describing why NXDOMAIN is treated as untrustworthy by default though. :)

kerem commented

2026-03-16 01:03:45 +03:00

Author

Owner

@djc commented on GitHub (Jul 3, 2024):

Yeah, I think that's deep lore -- I think @bluejekyll must have explained at some point in the past, but not sure where...

There was also https://github.com/hickory-dns/hickory-dns/pull/1556.

@djc commented on GitHub (Jul 3, 2024): Yeah, I think that's deep lore -- I think @bluejekyll must have explained at some point in the past, but not sure where... There was also https://github.com/hickory-dns/hickory-dns/pull/1556.

kerem commented

2026-03-16 01:03:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Aug 11, 2024):

for reference, the untrusted NXDOMAIN response is due to misconfigured DNS at various companies where the internal DNS ends up responding as authoritative for domains it technically does not manage. I had originally wanted to just chalk that up to "your company has a badly configured DNS", but that meant that in those situations users didn't have an option for make the resolver work in that context.

@bluejekyll commented on GitHub (Aug 11, 2024): for reference, the untrusted NXDOMAIN response is due to misconfigured DNS at various companies where the internal DNS ends up responding as authoritative for domains it technically does not manage. I had originally wanted to just chalk that up to "your company has a badly configured DNS", but that meant that in those situations users didn't have an option for make the resolver work in that context.