Minimal NSEC range not accepted for top level domains

[buffrr]

In RFC4470 section 4 for minimally covering NSEC records. To get the immediate lexicographic successor of a name, add a leading label with a single null (zero-value) octet.

For example, the immediate successor for nlnetlabs.nl is \000.nlnetlabs.nl so we can create the following proof (which works)

nlnetlabs.nl  300 IN NSEC \000.nlnetlabs.nl A TXT SOA AAAA NSEC RRSIG
nlnetlabs.nl  300 IN RRSIG NSEC 8 2 300 ....

I have a root zone with top level names. Some of these do not have a DS record, so I have an insecure delegation proof:

example.  300 IN NSEC \000.example. NS RRSIG NSEC
example.  300 IN RRSIG NSEC 8 1 300 .... 

Unbound is configured as a recursive resolver for the root server (with my own root KSK). It marks the response as bogus "no DS for ...." but the following works (a larger range)

example.  300 IN NSEC example\000. NS RRSIG NSEC
example.  300 IN RRSIG NSEC 8 1 300 .... 

Is there an issue here with unbound or I'm I missing something?

[wcawijngaards]

Do you have the verbosity 4 trace of this, so I can see what it does?

From a quick look at the code, the code for NSEC referral match does not look at the next name. Unless there is like a wildcard or an empty-nonterminal that the proof is for. It should just pick up the NSEC rrset from the authority section, by name, and check the type bitmap.

[buffrr]

I noticed the line sanitize: removing overreaching NSEC RRset: to. NSEC IN which is interesting. Log with verbosity 4 here

If i dig @127.0.0.56 to ns +dnssec, there is an NSEC record in the authority section (127.0.0.56 is the root server ip address)

to.                     10800   IN      NSEC    \000.to. NS RRSIG NSEC
to.                     10800   IN      RRSIG   NSEC 13 1 10800 20220315183806 20210314183806 60944 . Mdu1JDLm1VaVo41y3j+d1gaoMc5NfyubsLIPRUPuu4VQcVu/IByy9Vcc zYFSFy0cc/YIve/fganiulVG9LSgqg==

also dig @127.0.0.56 to ds +dnssec

;; QUESTION SECTION:
;to.                            IN      DS

;; AUTHORITY SECTION:
.                       86400   IN      SOA     . . 2021031518 1800 900 604800 86400
.                       10800   IN      RRSIG   SOA 13 0 86400 20220315183806 20210314183806 60944 . hUc54wog4JQ5jq55ZUHbAz8XTgiYfRLPJETWceKO/vMbXgpY+0aEUD7w nxiwWfxUpTclD248QWuWx163QidmMw==
to.                     10800   IN      NSEC    \000.to. NS RRSIG NSEC
to.                     10800   IN      RRSIG   NSEC 13 1 10800 20220315183806 20210314183806 60944 . Mdu1JDLm1VaVo41y3j+d1gaoMc5NfyubsLIPRUPuu4VQcVu/IByy9Vcc zYFSFy0cc/YIve/fganiulVG9LSgqg==

queries to .to return servfail

[wcawijngaards]

The overreaching error looks like it is the cause. Unbound is perhaps configured wrong, and when it looks up the to. DS record it thinks it is querying a TLD server, not the root server. If you had the verbosity 4 logs, unbound would say what server bailiwick it is contacting. The issue is that the right hand nsec name is outside of the bailiwick, and this is not accepted by unbound. It could also be that the NSEC record is malformed, but dig does not complain, so I assume it is the bailiwick check that is failing.

[wcawijngaards]

The issue is caused by a compressed domain name in the NSEC record. Unbound is very lenient and decompresses a lot of domain names, even though that is not required. But not this one, so I fixed that. The commit does that and that should fix your issue.

However, you should realize that NSEC right hand domain names are not subject to domain name compression. This is not allowed by the RFCs that defined it [RFC4034, RFC4035], to make it unknown-resource-record compatible. The sending target server, therefore, has to be fixed to not apply compression to non-compressible domain names, such as the next name in the NSEC record.