> Matthew Pounsett <mailto:[email protected]> > 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
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
