NSEC RR

[patch-work]

I used NSEC3 until the deprecation of SHA1. In my head, since SHA1 is deprecated, then NSEC3 is also deprecated, because its available DNSSEC algorithms are DSA-NSEC3-SHA1 and RSASHA1-NSEC3-SHA1. Having to replace the Algo, I started using ED25519 as recommended by RFC 8624 and, I hereby confess my sin, I forgot about NSEC3. Years passed by and a new version of NSD included the option "--disable-nsec3", because "with NSEC3 support enabled, very large zones, also non-NSEC3 zones, use about 20% more memory". My nsd server was still compiled with nsec3. As I am upgrading, what is the best current practice on how to implement NSEC? How is NLnetlabs implementing NSEC on its own servers?

This is what I see from the DNS wizard:

https://dnsviz.net/d/nlnetlabs.nl/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

That is

> unbound-host -rvD -tNSEC nlnetlabs.nl
nlnetlabs.nl has NSEC record !.nlnetlabs.nl. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY (secure)

This means that NLnetlabs is not using NSEC3.

It also means that their DNS includes the following RR:

@ IN NSEC !.@ (A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY)

If I use the same approach, however, my nsd server translates "!.@" into "_dane.@":

> unbound-host -rvD -tNSEC example.org
example.org has NSEC record _dane.example.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY (secure)

I do have relevant DANE RRs. To simplify their management, I use CNAME:

> unbound-host -rvD -tTLSA _25._tcp.example.org
_25._tcp.example.org is an alias for _dane.example.org. (secure)
_dane.example.org has TLSA record 3 1 1 [omissis] (secure)

No RFC forbids using CNAME as I do, if memory does not fail me, and NLnetlabs is doing the same:

> unbound-host -rvD -tTLSA _25._tcp.nlnetlabs.nl
_25._tcp.nlnetlabs.nl is an alias for 3.1.1._dane-gs.nlnetlabs.nl. (secure)
3.1.1._dane-gs.nlnetlabs.nl has TLSA record 3 1 1 [omissis] (secure)

The only difference here is the use of a "3.1.1._dane" prefix instead of my simpler "_dane" prefix. Out of curiosity, I changed my own prefix, and the result did not change:

> unbound-host -rvD -tNSEC example.org
example.org has NSEC record 3.1.1._dane.example.org. A NS SOA MX TXT RP RRSIG NSEC DNSKEY CAA (secure)

So, why my nsd server is translating "!.@" into "_dane.@" or "3.1.1._dane.@" instead of "!.@"?

[wtoorop]

Hi @patch-work . That text about "--disable-nsec3" in the README is from 2008. It is not related to the deprecation of SHA1. Even though SHA1 is deprecated for the signing algorithms, it is not for hashing the name in "private" authenticated denial of existence that NSEC3 provides. NSEC3 is not deprecated. It also has the opt-out feature which is very important to delegation heavy zones with limited DNSSEC delegations. That said, if your zone is not large, and you don't mind zone-walking, then NSEC is perfectly fine to use instead of NSEC3. NSECs covers the gaps between the names. The names are first sorted in canonical order. The NSEC on the apex contains the first name that exists in the zone after the apex in canonical order. We do have a TXT RRset on !.@ in the nlnetlabs.nl zone, hence that is the rdata field of the NSEC RR on the apex. With your zone, the first name after the apex in canonical order is _dane.@. So that is all good. There is a very nice short paper on authenticated denial of existence by Miek Gieben en Matthijs Mekking, which you can find here: https://www.sidnlabs.nl/downloads/Z0FQoNNjTRSwc1LTMrF7gQ/c2f8431b9b995c5671347d6a239a6b9b/wp-2011-0x01-v2.pdf It is a very nice read and even though it is from 2012, it is still actual. I can recommend it!

[patch-work]

> unbound-host -rvD -tTXT !.nlnetlabs.nl
!.nlnetlabs.nl has TXT record "So NSEC convering the wildcard comes from here" (secure)

I see it. Thank you!

[patch-work]

New NSEC RR:

! IN TXT "No NSEC convering the wildcard comes from here"
@ IN NSEC ! ( SOA A AAAA NS NSEC MX TXT NAPTR RRSIG DNSKEY )

[patch-work]

This is also a nice short paper to read:

https://blog.nlnetlabs.nl/aggressive-use-of-the-dnssec-validated-cache-in-unbound/

[wtoorop]

This is also a nice short paper to read:

https://blog.nlnetlabs.nl/aggressive-use-of-the-dnssec-validated-cache-in-unbound/

Thanks :+1: I agree! Very nice short paper.