NSEC3 informing NSEC implementations

I went to OARC 32 last weekend. I’m not really going to summarize the event, since you should be able to view the presentions yourself. The most gratifying session for me was an early one: Brian Somers’ talk on implementing DNSSEC for Cisco OpenDNS (“Recursive Resolution From the Ground Up”.)

I enjoyed this talk both because it is always fun to hear about other’s development experiences, and because he was basically describing challenges that I’d gone through myself, albeit 15 years earlier. In particular, on slide ten Brian says “NSEC3 was harder; Ironically it cleaned up our NSEC implementation.” This might have been surprising (or non-committal) to most of the audience, but it resonated with me. That is because, when working on defining NSEC3, I realized that NSEC3 was really the same algorithm as NSEC, but with all the steps becoming explicit. (I said basically this 12 years ago too.)

Of course, in the intervening period, some smart people wrote a very nice RFC explaining all of the concepts around NSEC and NSEC3: RFC 7129.

I do think that this is relationship is somewhat hard to see, particularly because NSEC (neé NXT) is somewhat intuitive. Once you wrap your head around the basic concept of “cryptographic denial of existance”, the idea that I have a record that says “there is nothing between this and that name” isn’t all that hard to understand. When you then move on to understanding NSEC3, while the actual concept is the same, it is much less intuitive. We aren’t used to working in “hash space”, and there are corner cases to NSEC3 that didn’t appear to exist for NSEC.

Take:

b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC

You don’t realize that the NSEC record is also telling you the closest encloser (in this case, example..) With NSEC3, however, has to establish the closest encloser explicitly (using the closest encloser proof).