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

[Doug Barton]

On 12/1/14 9:03 PM, Paul Vixie wrote:
> i apologize for not saying so explicitly: nothing can directly validate
> the contents of the glue records. two indirect methods exist, which are
> (1) looking it up in a validating RDNS and seeing if the content of the
> glue record you got with your zone is the same as the one signed by
> DNSSEC, in a provisional validation environment that asks "what if this
> glue is correct?", and (2) using the glue and noting whether the zones
> reached by that NS+glue are signed with a key matching that zone's
> signed DS RR. if they are signed with the right key then it doesn't
> matter whether the address glue was correct or not.
>
> but you raise a very interesting issue, which is that the definition of
> "zone" does not include address glue. if the per-zonefile or per-axfr
> signature that you'd like to bind to the zone has to cover its glue,
> then we have a very interesting set of new problems, like does this mean
> all address glue or only necessary address glue (under our leaf
> delegations), does it include both A and AAAA RR's, which one is hashed
> first, and so on. all those rules would have to be spelled out in any
> signature that was made over "all the stuff you get in an AXFR, or that
> you might find in a zone file sitting on disk" rather than made over
> "the zone".
>
> since NS RR's aren't signed in the parent, a zone-walk won't verify
> them, and perhaps that's your most compelling argument for some new
> signature which does cover those, since any unsigned child could be
> spoofed if the zone file (or AXFR contents) were tampered with.

Paul V.,

Thanks for responding to Paul H. on the topic I raised a couple of days 
ago. :) (I mentioned delegation NS records, since they are less 
controversial than actual glue, but it's the same issue.) While what you 
propose can be done, it would add more complexity than a simple zone 
signature that covers the entire zone.

In any case, now that you've acknowledged that DNSSEC doesn't cover the 
intended use case, perhaps we can dispense with that line of argument?

Doug