Re: [dnsext] NSEC4

["Blacka, David" <[e-mail]>]

On Jan 4, 2012, at 4:29 AM, Miek Gieben wrote:

> Dear dnsext,
> 
> We have written down a little experiment that we have performed, called NSEC4.
> The goal of the experiment was to optimize denial of existence records.
> It is not our intention to standardize this, as we are aware of the backwards
> compatibility issues this has with the current DNSSEC family RFCs, and we do
> not want to discomfort the ongoing DNSSEC deployment.
> 
> However, we do want to document this to archive the insights we have gained
> by doing this experiment. Therefor, we have submitted the following draft:
> 
>    http://www.ietf.org/id/draft-gieben-nsec4-00.txt
> 
> This experiment resolves two things:
> * Reduces the size of the denial of existence response;
> * Adds Opt-Out to un-hashed names.
> 
> We would be grateful if you would like to read this.
> 
> Our question is what is the best place to archive this? Re-reading RFC 2026,
> we are considering to put this on the experimental non-standards track.
> 
> Thoughts?

Interesting!  As Roy points out, we did consider these ideas while working on NSEC3, but decided that adding them would make the analysis of NSEC3 even harder for the working group, so decided to leave them out.

I note that with zero hashing, NSEC4 doesn't look exactly like NSEC, as you will have NSEC4 records at empty non-terminals.  This is the reason (that is, the ability to find a record for every possible closest encloser) that the order doesn't have to be DNSSEC canonical name order, and thus could be byte order as Ben suggests.

Since this is an experiment, why not also experiment with a different type map encoding?  I've generally thought that the current encoding isn't typically space or computationally optimal.

--
David Blacka                          <[e-mail]> 
Principal Engineer      Verisign Infrastructure Engineering

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext