[GH-ISSUE #2299] `dig +dnssec NS nameservers.com.` does not include RRSIG records #959

New issue

Closed

opened 2026-03-16 01:05:56 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 01:05:56 +03:00

Owner

Originally created by @japaric on GitHub (Jul 9, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2299

Originally assigned to: @japaric on GitHub.

Describe the bug
what the title says

To Reproduce
Steps to reproduce the behavior:

run cd conformance && DNS_TEST_SUBJECT="hickory $(dirname $(pwd))" cargo r --example explore -- --dnssec
log into the "resolver" container and modify /etc/named.toml to change the dnssec_policy to "ValidationDisabled"
in the "resolver" container run a new hickory-dns instance. you'll need to bind a port other than 53.
from the "client" container run dig @$RESOLVER_IP_ADDR -p $PORT NS nameservers.com.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
nameservers.com.	86400	IN	NS	primary1.nameservers.com.

Expected behavior
The response should include a RRSIG record that covers the NS record

System:

OS: Ubuntu
Architecture: x86_64
Version 22.04
rustc version: 1.79

Version:
Crate: hickory-dns
Version: dab09034dd

Additional context

The problem seems to that during the recursive resolution a response from the com. nameserver that includes a NS record without a RRSIG (+) gets cached and that cached response is returned by the resolver without sending the NS nameservers.com. query to the nameservers.com. nameserver, whose response would have included the missing RRSIG record.

I think this bug is behind the DNSSEC validation problem observed in #2285 . that is, fixing this should also fix #2285.

(+) no RRSIG is expected because com. cannot sign the NS nameservers.com. record. the nameservers.com. nameserver must sign it

Originally created by @japaric on GitHub (Jul 9, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2299 Originally assigned to: @japaric on GitHub. **Describe the bug** what the title says **To Reproduce** Steps to reproduce the behavior: 1. run `cd conformance && DNS_TEST_SUBJECT="hickory $(dirname $(pwd))" cargo r --example explore -- --dnssec` 2. log into the "resolver" container and modify `/etc/named.toml` to change the `dnssec_policy` to `"ValidationDisabled"` 3. in the "resolver" container run a new hickory-dns instance. you'll need to bind a port other than 53. 4. from the "client" container run `dig @$RESOLVER_IP_ADDR -p $PORT NS nameservers.com.` ``` console ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48530 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; ANSWER SECTION: nameservers.com. 86400 IN NS primary1.nameservers.com. ``` **Expected behavior** The response should include a RRSIG record that covers the NS record **System:** - OS: Ubuntu - Architecture: x86_64 - Version 22.04 - rustc version: 1.79 **Version:** Crate: `hickory-dns` Version: dab09034dde8120e902b4786e4ff9024697736f1 **Additional context** The problem seems to that during the recursive resolution a response from the `com.` nameserver that includes a NS record *without* a RRSIG (+) gets cached and that cached response is returned by the resolver without sending the `NS nameservers.com.` query to the `nameservers.com.` nameserver, whose response would have included the missing RRSIG record. I think this bug is behind the DNSSEC validation problem observed in #2285 . that is, fixing this should also fix #2285. (+) no RRSIG is expected because `com.` cannot sign the `NS nameservers.com.` record. the `nameservers.com.` nameserver must sign it