[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

> Matthew Pounsett <mailto:matt at conundrum.com>
> Saturday, November 29, 2014 3:03 PM
>
> Those zones are relatively rare though, and reading a randomly-written
> mmaped file isn't a common name server implementation. That seems to
> me to be optimizing for an edge case at the expense of the common
> case. Zones which fall into that rather narrow edge case can simply
> not use this proposed signature.

if we were discussing an in-band protocol signal, then an applicability
statement along those lines would make sense to me. since we're
discussing an out-of-band zone transfer, i'm trying to understand how we
can specify anything at all about how it behaves, beyond a
recommendation that if out-of-band transfer is used, then zone integrity
checking should be done. notefully: rsync's use of TCP is, to me, strong
enough to protect zone integrity.

in other words, for in-band transfers (AXFR, IXFR, and to some extent
UPDATE), the obvious in-band integrity check would be (a) also in-band,
(b) incremental, and (c) dnssec-based. there would be no benefit to the
in-band case from paying the cost of maintaining an in-band zone
signature, even if someone knows a way to incrementally update a secure
hash after an IXFR or UPDATE. whereas in the out-of-band transfer case,
the out-of-band transferee is going to have to touch every byte and is
the obvious actor to burden with integrity checking, but, if we want the
secondary server to do integrity checking after an AXFR or IXFR, it
should be zone walking, not just comparing some as-yet-nonexistent
secure-yet-updateable zone-level hash.

every bit of logic and arithmetic we add to the world's dns
implementations increases DNS's attack surface due to the inevitability
of bugs. before we add something like a zone-level hash, i'd like us all
to be sure it solves a problem in a uniquely excellent way. for example,
dan kaminsky proposed several years ago that a stub be able to request,
by EDNS, the full RRSIG/DNSKEY/DS chain from the qname upward to some
specified TA, to permit stub validation without requiring a stub cache
or to spend many round trips on a validation. that would be complexity
worth adding, because it has a clear use case and it enables something
that's impractical today (last-mile validation).

it's a terrible loss to us all that the roads not taken in DNSSEC
weren't recorded as well as the roads taken. zone-level signatures were
proposed, debated, and not merely failed to find consensus in favour,
but actually found consensus against. now we're starting over without
the benefit of knowing why this was deliberately not put into DNSSEC in
the first place.

vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141129/dd24009a/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/20141129/dd24009a/attachment.jpg>