[GH-ISSUE #1926] Try next DNS server when the first one doesn’t have the requested type #820

New issue

Open

opened 2026-03-16 00:24:26 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 00:24:26 +03:00

Owner

Originally created by @GoldsteinE on GitHub (May 5, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1926

Is your feature request related to a problem? Please describe.
Sometimes the first DNS server returns a truncated response, that contains some records (e.g. CNAME record), but not the requested records (e.g. A record for this CNAME). Currently trust-dns-resolver returns an error for this case without trying the next server.

Describe the solution you'd like
When the first DNS server tried returns a (truncated?) response that doesn’t contain the requested record, try the next one.

Describe alternatives you've considered
If .lookup() returned the server that was used to get these results on error, user could possibly just retry the request themselves.

Of course, this feature could be configurable, with something like

enum RetryIncomplete {
    Never, // current behaviour
    WhenTruncated, // only try the next server when response is truncated
    Always, // always try the next server when response doesn't contain a record with requested type
}

Also trust-dns could retry the request over TCP in this case. I’d think that try_tcp_on_error would do it, but apparently it doesn’t.

Originally created by @GoldsteinE on GitHub (May 5, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1926 **Is your feature request related to a problem? Please describe.** Sometimes the first DNS server returns a truncated response, that contains _some_ records (e.g. CNAME record), but not the requested records (e.g. A record for this CNAME). Currently trust-dns-resolver returns an error for this case without trying the next server. **Describe the solution you'd like** When the first DNS server tried returns a (truncated?) response that doesn’t contain the requested record, try the next one. **Describe alternatives you've considered** If `.lookup()` returned the server that was used to get these results on error, user could possibly just retry the request themselves. Of course, this feature could be configurable, with something like ```rust enum RetryIncomplete { Never, // current behaviour WhenTruncated, // only try the next server when response is truncated Always, // always try the next server when response doesn't contain a record with requested type } ``` Also trust-dns could retry the request over TCP in this case. I’d think that `try_tcp_on_error` would do it, but apparently it doesn’t.

kerem commented

2026-03-16 00:24:32 +03:00

Author

Owner

@djc commented on GitHub (May 18, 2023):

Also trust-dns could retry the request over TCP in this case. I’d think that try_tcp_on_error would do it, but apparently it doesn’t.

Maybe that's a bug? You didn't provide many details about the specific error you're getting.

@djc commented on GitHub (May 18, 2023): > Also trust-dns could retry the request over TCP in this case. I’d think that `try_tcp_on_error` would do it, but apparently it doesn’t. Maybe that's a bug? You didn't provide many details about the specific error you're getting.

kerem commented

2026-03-16 00:24:37 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 20, 2023):

There's also the trust_nx_responses setting, it defaults to false, though it might only apply to NX_DOMAIN, and not to empty record_sets when the name exists but a particular type does not. I can't remember the implementation details off the top of my head and would need to look at the implementation to see.

@bluejekyll commented on GitHub (Jun 20, 2023): There's also the [`trust_nx_responses`](https://docs.rs/trust-dns-resolver/0.22.0/trust_dns_resolver/config/struct.NameServerConfig.html#structfield.trust_nx_responses) setting, it defaults to false, though it might only apply to NX_DOMAIN, and not to empty record_sets when the name exists but a particular type does not. I can't remember the implementation details off the top of my head and would need to look at the implementation to see.

kerem commented

2026-03-16 00:24:42 +03:00

Author

Owner

@GoldsteinE commented on GitHub (Jun 23, 2023):

Maybe that's a bug? You didn't provide many details about the specific error you're getting.

I’m getting a “response truncated” error, but it’s hard to reproduce, because it only happens sometimes, with some hosts and specific DNS servers. I’ll write details if I’m able to create an example that reproduces at least somewhat reliably.

@GoldsteinE commented on GitHub (Jun 23, 2023): > Maybe that's a bug? You didn't provide many details about the specific error you're getting. I’m getting a “response truncated” error, but it’s hard to reproduce, because it only happens sometimes, with some hosts and specific DNS servers. I’ll write details if I’m able to create an example that reproduces at least somewhat reliably.