[GH-ISSUE #2150] Presence of a faulty nameserver in system config causes client side lookups to take forever #902

New issue

Open

opened 2026-03-16 00:49:16 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 00:49:16 +03:00

Owner

Originally created by @bergentruckung on GitHub (Feb 20, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2150

Describe the bug
If there's a faulty nameserver (non-existent/typo or dummy) in /etc/resolv.conf along with others that are working, the lookup gets stalled (in my case, up to 16s). Would it be possible for the client side lookup to rely on the nameservers in order (from top to bottom), or have an alternate strategy of returning the first successful lookup?

To Reproduce

Add any non-existent IP to list of nameservers in /etc/resolv.conf
Try running resolve -s google.com

Expected behavior
DNS lookup to be quick.

System:

OS: RHEL8
Architecture: x86_64
rustc version: [e.g. 1.73]

Version:
Crate: [e.g. client, server, resolver]
Version: [e.g. 0.24.0]

Originally created by @bergentruckung on GitHub (Feb 20, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2150 **Describe the bug** If there's a faulty nameserver (non-existent/typo or dummy) in `/etc/resolv.conf` along with others that are working, the lookup gets stalled (in my case, up to 16s). Would it be possible for the client side lookup to rely on the nameservers in order (from top to bottom), or have an alternate strategy of returning the first successful lookup? **To Reproduce** 1. Add any non-existent IP to list of nameservers in `/etc/resolv.conf` 2. Try running `resolve -s google.com` **Expected behavior** DNS lookup to be quick. **System:** - OS: RHEL8 - Architecture: x86_64 - rustc version: [e.g. 1.73] **Version:** Crate: [e.g. client, server, resolver] Version: [e.g. 0.24.0]

kerem commented

2026-03-16 00:49:22 +03:00

Author

Owner

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

It would be good to dig into more detail on this. This ends up calling AsyncResolver::inner_lookup(), but it would be good to understand what the ResolverConfig and ResolverOpts look like in this case. Unfortunately I won't be able to dig into this much more, but happy to provide guidance if you're able to provide more details on the behavior you're seeing.

@djc commented on GitHub (Feb 28, 2024): It would be good to dig into more detail on this. This ends up calling `AsyncResolver::inner_lookup()`, but it would be good to understand what the `ResolverConfig` and `ResolverOpts` look like in this case. Unfortunately I won't be able to dig into this much more, but happy to provide guidance if you're able to provide more details on the behavior you're seeing.