[dns-operations] Assuring the contents of the root zone

[Paul Vixie]

> George Michaelson <mailto:ggm at apnic.net>
> Monday, December 01, 2014 5:56 PM
> Here is a strawman, to try and understand the discussion.
>
> ...
>
> Why is this worse than eg an RR by RR comparison, walking the NSEC
> chains? What I like about it, is that its applicable to being given
> the data OOB. if you have what is a putative zone, then you can apply
> this logic, and determine if the zone matches what is published
> elsewhere as a canonical state of the zone.
>
> The RR by RR and NSEC walk feels like a DNS experts approach. Not a
> systems/generic approach.

if we change the use case to 'tertiary server operator wants to be sure
zone is correct' where correct means not just that it came from the
authorized source and has not been tampered with, but also that the
authorized source did not bungle their duties, then a zone level
signature whether in-band or detached would not be adequate. it would
literally be nec'y to ensure that there are no records between the
NSEC's and that every RRSIG matches its RRset and no RRsigs are
extraneous and no RRsets (other than as permitted by "opt out") remain
unsigned.

in my own history of having once operated a COM/NET/ORG secondary (which
all the root name servers did for many years), the only time we had an
emergency was when the zone generation logic had a failure, and there
were a lot of missing subdomains for a few minutes/hours. a zone-level
signature might not have caught that, depending on where in the work
flow that signature (whether in-band or detached) was generated.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/e854d5e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/e854d5e4/attachment.jpg>