[dns-operations] Some DNSSEC trivia

[Edward Lewis]

At 18:02 +0100 1/7/08, Francis Dupont wrote:

>=> it is easy to check this hypothesis: just compile the zone before
>loading/signing/etc by named-compilezone (same binary than
>named-checkzone, and same man).

Had I been tasked to write to that assumption, the whole task would 
have been simpler.  But back then we didn't want to assume that the 
input would be orderly.  This was in the days where there were even 
non-delegations in the .com zone file.  Registries weren't fully 
automated.

>
>    If it weren't for having to have a canonical ordering for the
>    non-existence proofs, signing a zone would only need to make sure the
>    RR sets were compiled.
>
>=> so NSEC3 should help?

No, NSEC3 needs to be canonically ordered too - each hashed name must 
find the next name in the canonical order.  Of course, with opt-in, 
the number of NSEC3 names to sort may be much less than the number of 
names in the zone.

NSEC3 has tremendous upsides for large zones if there's no vast 
uptake in DNSSEC. ;)

>PS: BTW BIND uses an ordered tree structure (red-black tree) for storing zones
>so the issue is not the canonical ordering...

For zones, yes, but in older BIND versions it didn't use the 
red-black tree for the contents of zones.  Back in the day it used a 
hash table for the contents of zones.  The has table had to be 
removed in favor of a tree to accommodate DNSSEC, one of the 
"improvements" needed by DNSSEC that caused BIND 9 to come into 
being.  Remember when BIND 9 was considered to be slower than BIND 8? 
If I learned corretly, that was a symptom of the change from a hash 
table to a tree.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.