[dns-operations] Some DNSSEC trivia
Ed.Lewis at neustar.biz
Mon Jan 7 17:51:52 UTC 2008
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
> 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
Think glocally. Act confused.
More information about the dns-operations