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 #1187] Can not query Glue Records with Resolver #625

New issue

Closed

opened 2026-03-15 23:30:58 +03:00 by kerem · 8 comments

kerem commented

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

Owner

Originally created by @wavenator on GitHub (Aug 11, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1187

What I was trying to do is to query one of the Tld Nameservers com - a.gtld-servers.net. 192.5.6.30 for the NS record of google.com.
The result is an error:

ResolveError {
    kind: NoRecordsFound {
        query: Query {
            name: Name {
                is_fqdn: true,
                labels: [google, com]
            },
            query_type: NS,
            query_class: IN
        },
        valid_until: None
    },
    backtrack: None
}

To Reproduce

use trust_dns_resolver::Resolver;
use trust_dns_resolver::config::*;

fn main() {
    let mut resolver_config = ResolverConfig::new();
    resolver_config.add_name_server(
        NameServerConfig {
            socket_addr: "192.5.6.30:53".parse().unwrap(),
            protocol: Protocol::Udp,
            tls_dns_name: None,
        }
    );
    let resolver = Resolver::new(resolver_config, ResolverOpts::default()).unwrap();

    resolver.ns_lookup("google.com.").unwrap();
}

Expected behavior
Getting a list of Authoritative Nameservers

System:

OS: Fedora Linux
Architecture: x86_64
Version 32
rustc version: 1.45.2

Version:
Crate: resolver
Version: 0.19.5

Originally created by @wavenator on GitHub (Aug 11, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1187 What I was trying to do is to query one of the Tld Nameservers `com - a.gtld-servers.net. 192.5.6.30` for the NS record of `google.com.` The result is an error: ```rust ResolveError { kind: NoRecordsFound { query: Query { name: Name { is_fqdn: true, labels: [google, com] }, query_type: NS, query_class: IN }, valid_until: None }, backtrack: None } ``` **To Reproduce** ```rust use trust_dns_resolver::Resolver; use trust_dns_resolver::config::*; fn main() { let mut resolver_config = ResolverConfig::new(); resolver_config.add_name_server( NameServerConfig { socket_addr: "192.5.6.30:53".parse().unwrap(), protocol: Protocol::Udp, tls_dns_name: None, } ); let resolver = Resolver::new(resolver_config, ResolverOpts::default()).unwrap(); resolver.ns_lookup("google.com.").unwrap(); } ``` **Expected behavior** Getting a list of Authoritative Nameservers **System:** - OS: Fedora Linux - Architecture: x86_64 - Version 32 - rustc version: 1.45.2 **Version:** Crate: resolver Version: 0.19.5

kerem

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

closed this issue
added the
bug

crate:resolver
labels

kerem commented

2026-03-15 23:31:14 +03:00

Author

Owner

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

Thank you for the report. I'm wondering if there is a resolution expectation here that isn't being met. The Resolver currently won't traverse the graph as necessary to go from the root name server to the glue records. This requires recursive resolution, which isn't (yet) implemented by the resolver.

If you could enable logging for the resolver, debug would probably be enough, and that would probably show that the query to the root node is getting no records as a response.

@bluejekyll commented on GitHub (Aug 11, 2020): Thank you for the report. I'm wondering if there is a resolution expectation here that isn't being met. The Resolver currently won't traverse the graph as necessary to go from the root name server to the glue records. This requires recursive resolution, which isn't (yet) implemented by the resolver. If you could enable logging for the resolver, `debug` would probably be enough, and that would probably show that the query to the root node is getting no records as a response.

kerem commented

2026-03-15 23:31:19 +03:00

Author

Owner

@wavenator commented on GitHub (Aug 11, 2020):

The problem with glue records is where the response lays in the packet. Specifically, it lays inside the Authority RRs. When the Answer RRs are empty (as in that case), the library panics with NoRecordsFound

@wavenator commented on GitHub (Aug 11, 2020): The problem with glue records is where the response lays in the packet. Specifically, it lays inside the Authority RRs. When the Answer RRs are empty (as in that case), the library panics with `NoRecordsFound`

kerem commented

2026-03-15 23:31:24 +03:00

Author

Owner

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

Ah, I see. Today we only use the answers and additionals sections of the response for looking for records. That happens here:

https://github.com/bluejekyll/trust-dns/blob/main/crates/resolver/src/lookup_state.rs#L298-L301

To fix this we could simply chain the authorities section into the that search like the additionals, and that would fix this particular issue. I was being conservative in the search of the response packet before, but maybe we should just include it?

@bluejekyll commented on GitHub (Aug 11, 2020): Ah, I see. Today we only use the `answers` and `additionals` sections of the response for looking for records. That happens here: https://github.com/bluejekyll/trust-dns/blob/main/crates/resolver/src/lookup_state.rs#L298-L301 To fix this we could simply `chain` the `authorities` section into the that search like the `additionals`, and that would fix this particular issue. I was being conservative in the search of the response packet before, but maybe we should just include it?

kerem commented

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

Author

Owner

@wavenator commented on GitHub (Aug 11, 2020):

I highly recommend chaining Authority RR too. Or at least stop returning NoRecordsFound. Using Wireshark I can see that the response not only included Authority RRs but also Additionals RRs

@wavenator commented on GitHub (Aug 11, 2020): I highly recommend chaining Authority RR too. Or at least stop returning NoRecordsFound. Using Wireshark I can see that the response not only included Authority RRs but also Additionals RRs

kerem commented

2026-03-15 23:31:35 +03:00

Author

Owner

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

I don't think I see any strong reason not to do this. Is this something you'd be interested in contributing a fix for?

@bluejekyll commented on GitHub (Aug 11, 2020): I don't think I see any strong reason not to do this. Is this something you'd be interested in contributing a fix for?

kerem commented

2026-03-15 23:31:40 +03:00

Author

Owner

@wavenator commented on GitHub (Aug 12, 2020):

I will definitely give it a try. I'll keep commenting here if I will get into trouble. Thanks!

@wavenator commented on GitHub (Aug 12, 2020): I will definitely give it a try. I'll keep commenting here if I will get into trouble. Thanks!

kerem commented

2026-03-15 23:31:45 +03:00

Author

Owner

@wavenator commented on GitHub (Aug 12, 2020):

#1188 Added a pull request

@wavenator commented on GitHub (Aug 12, 2020): #1188 Added a pull request

kerem commented

2026-03-15 23:31:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Aug 12, 2020):