<div dir="ltr">If somebody said to me:<div><br></div><div> "lets have a canonicalize() function which makes a deterministic byte-stream of the state of a zone, and then calculate a checksum over it"</div><div><br></div><div>I'd struggle to say that was a bad idea.</div><div><br></div><div>If you have a transform which takes updates in any kind, AXFR or IXFR and can then re-canonicalize and test the zone state against a known published record of the zone state, whats the downside?</div><div><br></div><div>I understand there is an element of redundency in the scheme, against what DNSSEC can alteady do at the RR level, but I think from whats been said, and what is being said about schemes to provide for re-distribution of the root, this makes a lot of sense.</div><div><br></div><div>The history only informs the present, it doesn't have to determine it. The statement about 'learning from history, doomed to repeat it' is not meant to say you cannot re-try things previously considered and rejected. It means you need to be aware of them.</div><div><br></div><div>-G</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 November 2014 at 07:18, Edward Lewis <span dir="ltr"><<a href="mailto:edward.lewis@icann.org" target="_blank">edward.lewis@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>After reading on…</div>
<div><br>
</div>
<div>I think the rationale of killing SIG(AXFR) was that DNSSEC is there to protect the relying party and not the manager of the zone. I.e., a relying party only cared about the data it received pertinent to the query it issued. This made the building the
chain of trust as efficiently as possible paramount. Forking into zone replication was a design distraction.</div>
<div><br>
</div>
<div>That’s not the reason SIG(AXFR) failed, that’s the reason we didn’t try harder to accomplish it. DNSSEC did not exist to make managing DNS better[0] (I.e., protect against zone truncation), so taking time to do that was hindering the primary purpose of
answering questions with proof of authenticity and integrity.</div>
<div><br>
</div>
<div>[0] Joke and snicker if you must. Yes DNSSEC today makes running today’s DNS harder, keep in mind that the state of the system in the 90’s was so bad that it would not have survived with the major rewrites DNSSEC development caused. DNSSEC didn’t have
a real good foundation to build upon.</div>
<div><br>
</div>
<span><span class="">
<div>
<div>On 11/27/14, 17:48, "Warren Kumari" <<a href="mailto:warren@kumari.net" target="_blank">warren@kumari.net</a>> wrote:</div>
</div>
<div><br>
</div>
</span><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div><span class=""><br>
<br>
On Thursday, November 27, 2014, Francisco Obispo <<a href="mailto:fobispo@uniregistry.link" target="_blank">fobispo@uniregistry.link</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>+1</div>
<div><br>
</div>
<div>And if someone is already serving the root zone, they can always modify the server to return AA.</div>
<div><br>
</div>
<div>I'm also wondering about the use case.</div>
</div>
</blockquote>
<div><br>
</div>
<div>See above - this has *nothing* to do with setting or not setting AA. This simply allows the entity serving a zone to confirm that they have a complete, uncorrupt, and untampered copy of the zone. Think of it as a cryptographic checksum if you like. </div>
Before serving a zone (as a master or slave) I'd like to know it is correct...
<div><br>
</div>
</span><div>W<span></span><br>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><span class="">
<div><br>
</div>
<div>Francisco Obispo</div>
<div><br>
On Nov 27, 2014, at 1:55 PM, Paul Vixie <<a>paul@redbarn.org</a>> wrote:<br>
<br>
</div>
</span><blockquote type="cite">
<div><br>
<br>
<blockquote style="border:0px none" type="cite"><span class="">
<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"><postbox-contact.jpg></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a style="color:#737f92!important;padding-right:6px;font-weight:bold;text-decoration:none!important">Warren Kumari</a></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle"><font color="#9FA2A5"><span style="padding-left:6px">Thursday, November 27, 2014 1:11 PM</span></font></div>
</div>
</div>
</span><span class=""><div style="color:#888888;margin-left:24px;margin-right:24px">... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others (who I embarrassing enough have forgotten) are planning on writing a "zone signature" draft (I have an initial version in
an edit buffet). The 50,000 meter view is:
<div>Sort all the records in canonical order (including glue)</div>
<div>Cryptographicly sign this</div>
<div>Stuff the signature in a record</div>
<div><br>
</div>
<div>This allows you to verify that you have the full and complete zone (.de...) and that it didn't get corrupted in transfer.</div>
<div>This solves a different, but related issue.<br>
</div>
</div>
</span></blockquote>
<br><span class="">
would this draft change the setting of the AA bit on an secondary server's responses, or make it unwilling to answer under some conditions? right now there is no dependency, AA is always set. but if we're going to make it conditional, then it should be conditioned
on the signatures matching all the way up-chain to a trust anchor, which would require an authority server to also contain a validator and be able to make iterative queries. so, i wonder about the use case for your draft.<br>
<br>
<div>-- <br>
Paul Vixie<br>
</div>
</span></div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><span class=""><br>
<span>dns-operations mailing list</span><br>
<span><a>dns-operations@lists.dns-oarc.net</a></span><br>
<span><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a></span><br>
<span>dns-jobs mailing list</span><br>
<span><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a></span></span></div>
</blockquote>
</div>
</blockquote>
</div><span class="">
<br>
<br>
-- <br>
I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.<br>
---maf<br>
</span></div>
</div>
</blockquote>
</span>
</div>
</blockquote></div><br></div>