[GH-ISSUE #2810] Authoritative name server does not send referral for queries at or below delegation point #1061

New issue

Open

opened 2026-03-16 01:29:32 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:29:32 +03:00

Owner

Originally created by @divergentdave on GitHub (Feb 27, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2810

Describe the bug
When a Hickory DNS name server receives a query for a name that it does not have authoritative data for, it does not return a referral. It only responds with NS records if the query itself is for NS records at exactly the delegation point.

To Reproduce
Steps to reproduce the behavior:

Start two testbeds with cargo run --example explore --manifest-path conformance/Cargo.toml and DNS_TEST_SUBJECT="hickory $(pwd)" DNS_TEST_PEER="hickory $(pwd)" cargo run --example explore --manifest-path conformance/Cargo.toml.
Start a shell in each client container using the docker exec commands in the output.
Make the following queries in each shell, against the root zone name server:
a. dig @172.XXX.0.4 hickory-dns.testing. A
b. dig @172.XXX.0.4 testing. A
c. dig @172.XXX.0.4 hickory-dns.testing. NS
d. dig @172.XXX.0.4 testing. NS

Expected behavior
Hickory DNS should not be returning AA (authoritative answer) responses for hickory-dns.testing. records, since it is below a zone cut. It should be returning NS records for a referral to the authoritative name server for the child zone in more cases.

Version:
Crate: hickory-server
Version: main

Additional context
This was encountered in #2807.

Originally created by @divergentdave on GitHub (Feb 27, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2810 **Describe the bug** When a Hickory DNS name server receives a query for a name that it does not have authoritative data for, it does not return a referral. It only responds with NS records if the query itself is for NS records at exactly the delegation point. **To Reproduce** Steps to reproduce the behavior: 1. Start two testbeds with `cargo run --example explore --manifest-path conformance/Cargo.toml` and `DNS_TEST_SUBJECT="hickory $(pwd)" DNS_TEST_PEER="hickory $(pwd)" cargo run --example explore --manifest-path conformance/Cargo.toml`. 2. Start a shell in each client container using the `docker exec` commands in the output. 3. Make the following queries in each shell, against the root zone name server: a. `dig @172.XXX.0.4 hickory-dns.testing. A` b. `dig @172.XXX.0.4 testing. A` c. `dig @172.XXX.0.4 hickory-dns.testing. NS` d. `dig @172.XXX.0.4 testing. NS` **Expected behavior** Hickory DNS should not be returning AA (authoritative answer) responses for `hickory-dns.testing.` records, since it is below a zone cut. It should be returning NS records for a referral to the authoritative name server for the child zone in more cases. **Version:** Crate: hickory-server Version: main **Additional context** This was encountered in #2807.

kerem added the

crate:server

compliance

labels

2026-03-16 01:29:32 +03:00

kerem commented

2026-03-16 01:29:43 +03:00

Author

Owner

@cpu commented on GitHub (Jul 30, 2025):

I think I just bumped into this using DNS_TEST_PEER="hickory" with the conformance testing explore.rs example w/ unbound acting as the recursive resolver (More debugging context in this Discord thread). In this configuration only the . Hickory nameserver is consulted for a query like dig @172.21.0.6 A nx.hickory-dns.testing., not testing. or hickory-dns.testing.

Switching to bind as the auth nameservers produces the expected results, and so does using HickoryDNS as the recursor with DNS_TEST_SUBJECT, in that case because of the more aggressive q-name minimization in the hickory resolver vs unbound.

cpu added crate:server and removed crate:recursor

I think this bug is specific to the auth server impl, and not the recursor (?)

@cpu commented on GitHub (Jul 30, 2025): I think I just bumped into this using `DNS_TEST_PEER="hickory"` with the conformance testing `explore.rs` example w/ `unbound` acting as the recursive resolver (More debugging context [in this Discord thread](https://discord.com/channels/590067103822774272/1400141201134321844)). In this configuration only the `.` Hickory nameserver is consulted for a query like `dig @172.21.0.6 A nx.hickory-dns.testing.`, not `testing.` or `hickory-dns.testing.` Switching to `bind` as the auth nameservers produces the expected results, and so does using HickoryDNS as the recursor with `DNS_TEST_SUBJECT`, in that case because of the more aggressive q-name minimization in the hickory resolver vs `unbound`. > cpu added crate:server and removed crate:recursor I think this bug is specific to the auth server impl, and not the recursor (?)

kerem commented

2026-03-16 01:29:48 +03:00

Author

Owner

@xi0 commented on GitHub (Feb 25, 2026):

I just bumped into this issue trying to move the zone cld.dk to hickory dns. The subdelegation is desk.cld.dk.

I moved the zone back to Google Cloud DNS for now. :(

@xi0 commented on GitHub (Feb 25, 2026): I just bumped into this issue trying to move the zone cld.dk to hickory dns. The subdelegation is desk.cld.dk. I moved the zone back to Google Cloud DNS for now. :(

kerem referenced this issue

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

[PR #1061] [MERGED] Bump h2 from 0.2.3 to 0.2.4 #1928

kerem referenced this issue

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

[PR #1061] [MERGED] Bump h2 from 0.2.3 to 0.2.4 #1931