<div dir="ltr">Here is a strawman, to try and understand the discussion.<div><br></div><div>If we imagine some datastream which is the result of an AXFR or HTTP request.</div><div><br></div><div> <cmd> | tr 'AZ' 'az'| sort -u | <checker> </div><div><br></div><div>this takes the stream, does LWSP replacement, and sorts the lines alphabetically and generates eg SHA256</div><div><br></div><div>the tr phase is just for example. presumably a more complex set of rules are required to DeMangLE the case conversion and punycode but the sense is, that we have a deterministic state of any label in the zone and its attributes as an encoding.</div><div><br></div><div>The sort phase generates a single understood (POSIX sort) order of bytes. These can then be compared.</div><div><br></div><div>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.</div><div><br></div><div>The RR by RR and NSEC walk feels like a DNS experts approach. Not a systems/generic approach.</div><div><br></div><div>-G</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2014 at 11:29, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<blockquote style="border:0px none" type="cite">
<div style="margin:30px 25px 10px 25px">
<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 src="cid:part1.04000107.00020302@redbarn.org" name="14a08a1a5589376a_compose-unknown-contact.jpg" height="25px" width="25px"></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a href="mailto:paul.hoffman@vpnc.org" style="color:#737f92!important;padding-right:6px;font-weight:bold;text-decoration:none!important" target="_blank">Paul Hoffman</a></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle"><font color="#9FA2A5"><span style="padding-left:6px">Monday, December 01, 2014 3:48 PM</span></font></div>
</div>
</div><span class="">
<div style="color:rgb(136,136,136);margin-left:24px;margin-right:24px">
<div>People have asked for two things:<br>
<br>
1) Getting the root zone by means other than AXFR, such as by HTTP<br>
<br>
2) Being sure that they got the exact root zone, including all of the glue records<br>
</div>
</div>
</span></blockquote>
<br>
i think you meant "zone" not "root zone" here.<span class=""><br>
<blockquote style="border:0px none" type="cite">
<div style="color:rgb(136,136,136);margin-left:24px;margin-right:24px">
<div><br>
A signed hash meets (2) regardless of how the zone was transmitted.<br>
</div>
</div>
</blockquote>
<br></span>
not inevitably. the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism. when i compare the complexity-cost of that tool to the contents of the
<a href="ftp://ftp.internic.net/domain" target="_blank"><ftp://ftp.internic.net/domain></a> directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can
 in some cases meet (2) far more easily than an in-band signature.<br>
<br>
it's also the case that rsync and similar tools (and AXFR) use TCP which most of us consider "reliable" even though its checksums aren't nearly as strong as SCTP's. therefore your problem statement "being sure they got the exact right zone" would have to refer
 to an MiTM, possibly inside the secondary server (if the zone receiver is a tertiary), or possibly on-path. in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based.<br>
<br>
and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data?<br>
<blockquote style="border:0px none" type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px">
<div><br>
...<span class=""><br>
Adding a record that says "here is a hash of this zone", and adding an RRSIG for that record, is the simplest solution. There are other solutions that are exactly as secure; however, they are all more complex, and some involve using the zone signing key for
 signing something other than the contents of an RRSIG.</span></div>
</div>
</blockquote>
i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler.<span class="HOEnZb"><font color="#888888"><br>
<br>
vixie<br>
</font></span></div>

</blockquote></div><br></div>