[GH-ISSUE #3293] section information being lost? #1165

New issue

Closed

opened 2026-03-16 01:46:59 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:46:59 +03:00

Owner

Originally created by @bryanlarsen on GitHub (Oct 1, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3293

Describe the bug
Hickory client doesn't retain section information

To Reproduce

$ ./target/debug/resolve -t NS google.ca
Querying for google.ca NS from udp:8.8.8.8:53, tcp:8.8.8.8:53, udp:8.8.4.4:53, tcp:8.8.4.4:53, udp:[2001:4860:4860::8888]:53, tcp:[2001:4860:4860::8888]:53, udp:[2001:4860:4860::8844]:53, tcp:[2001:4860:4860::8844]:53
Success for query google.ca. IN NS
        google.ca. 49260 IN NS ns1.google.com.
        google.ca. 49260 IN NS ns3.google.com.
        google.ca. 49260 IN NS ns2.google.com.
        google.ca. 49260 IN NS ns4.google.com.
        ns4.google.com. 308143 IN A 216.239.38.10
        ns1.google.com. 340784 IN A 216.239.32.10
        ns3.google.com. 308143 IN A 216.239.36.10
        ns2.google.com. 176344 IN A 216.239.34.10
        ns4.google.com. 308143 IN AAAA 2001:4860:4802:38::a
        ns1.google.com. 288356 IN AAAA 2001:4860:4802:32::a
        ns3.google.com. 308143 IN AAAA 2001:4860:4802:36::a
        ns2.google.com. 176344 IN AAAA 2001:4860:4802:34::a

Expected behavior
Dig tells us that the A & AAAA records returned are in the additional section rather than the answers section. This information is not available in the Lookup struct resolve uses, so resolve cannot print that information.

I believe that using hickory as a cache or forwarder will result in the same problem. It does for me, but I've got a hack setup that may also be the source of the problem. If unhacked hickory as cache or forwarder also exhibits the problem, this is a bug. If it doesn't, this is a feature request to have a method or methods to extract the 4 sections from Lookup, similar to what's available on Message.

A clear and concise description of what you expected to happen.

System:

OS: Debian
Architecture: AMD64
Version: Trixie
rustc version: 1.90

Version:
Crate: util & client
Version: 0.25.2

Additional context

Lookup contains records: Arc<[Record]> rather than separate lists for the 4 DNS sections.

It looks like that information is being lost in inner_lookup in caching_client.rs.

Willing to do the work myself, but changes to the Lookup struct will affect a lot of code so I'd like guidance on what sorts of changes would be accepted. We could put 4 lists in Lookup, put the Message in the Lookup rather than the records, or ...?

Originally created by @bryanlarsen on GitHub (Oct 1, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3293 **Describe the bug** Hickory client doesn't retain section information **To Reproduce** ``` $ ./target/debug/resolve -t NS google.ca Querying for google.ca NS from udp:8.8.8.8:53, tcp:8.8.8.8:53, udp:8.8.4.4:53, tcp:8.8.4.4:53, udp:[2001:4860:4860::8888]:53, tcp:[2001:4860:4860::8888]:53, udp:[2001:4860:4860::8844]:53, tcp:[2001:4860:4860::8844]:53 Success for query google.ca. IN NS google.ca. 49260 IN NS ns1.google.com. google.ca. 49260 IN NS ns3.google.com. google.ca. 49260 IN NS ns2.google.com. google.ca. 49260 IN NS ns4.google.com. ns4.google.com. 308143 IN A 216.239.38.10 ns1.google.com. 340784 IN A 216.239.32.10 ns3.google.com. 308143 IN A 216.239.36.10 ns2.google.com. 176344 IN A 216.239.34.10 ns4.google.com. 308143 IN AAAA 2001:4860:4802:38::a ns1.google.com. 288356 IN AAAA 2001:4860:4802:32::a ns3.google.com. 308143 IN AAAA 2001:4860:4802:36::a ns2.google.com. 176344 IN AAAA 2001:4860:4802:34::a ``` **Expected behavior** Dig tells us that the A & AAAA records returned are in the additional section rather than the answers section. This information is not available in the Lookup struct resolve uses, so resolve cannot print that information. I believe that using hickory as a cache or forwarder will result in the same problem. It does for me, but I've got a hack setup that may also be the source of the problem. If unhacked hickory as cache or forwarder also exhibits the problem, this is a bug. If it doesn't, this is a feature request to have a method or methods to extract the 4 sections from Lookup, similar to what's available on Message. A clear and concise description of what you expected to happen. **System:** - OS: Debian - Architecture: AMD64 - Version: Trixie - rustc version: 1.90 **Version:** Crate: util & client Version: 0.25.2 **Additional context** Lookup contains `records: Arc<[Record]>` rather than separate lists for the 4 DNS sections. It looks like that information is being lost in inner_lookup in caching_client.rs. Willing to do the work myself, but changes to the Lookup struct will affect a lot of code so I'd like guidance on what sorts of changes would be accepted. We could put 4 lists in Lookup, put the Message in the Lookup rather than the records, or ...?

kerem closed this issue

2026-03-16 01:47:04 +03:00

kerem commented

2026-03-16 01:47:10 +03:00

Author

Owner

@divergentdave commented on GitHub (Oct 1, 2025):

This is a known issue in the forwarder too, see #2781.

@divergentdave commented on GitHub (Oct 1, 2025): This is a known issue in the forwarder too, see #2781.

kerem commented

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

Author

Owner

@bryanlarsen commented on GitHub (Oct 1, 2025):

We can close as dupe, then. But either here or there if you give me an opinion on appropriate struct / API changes I'll take a stab at it.

@bryanlarsen commented on GitHub (Oct 1, 2025): We can close as dupe, then. But either here or there if you give me an opinion on appropriate struct / API changes I'll take a stab at it.

kerem referenced this issue

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

[PR #1165] [MERGED] Minor example.toml file fix at the README files #2031