<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:84185C42-F17F-4DFB-8B17-87CB7A5C4908@conundrum.com"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="matt@conundrum.com" photoname="Matthew Pounsett"
src="cid:part1.03050007.04050706@redbarn.org"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:matt@conundrum.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Matthew Pounsett</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Saturday,
November 29, 2014 3:03 PM</span></font></div></div></div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody"><div><!----><br>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.</div></div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
vixie<br>
</body></html>