<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; 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 id="OLK_SRC_BODY_SECTION"><div><div>On 11/27/14, 17:48, "Warren Kumari" <<a href="mailto:warren@kumari.net">warren@kumari.net</a>> wrote:</div></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div><br><br>
On Thursday, November 27, 2014, Francisco Obispo <<a href="mailto:fobispo@uniregistry.link">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><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"><div><br></div><div>Francisco Obispo</div><div><br>
On Nov 27, 2014, at 1:55 PM, Paul Vixie <<a href="javascript:_e(%7B%7D,'cvml','paul@redbarn.org');" target="_blank">paul@redbarn.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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"><postbox-contact.jpg></div><div style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%"><a href="javascript:_e(%7B%7D,'cvml','warren@kumari.net');" style="color:#737f92!important;padding-right:6px;font-weight:bold;text-decoration:none!important" target="_blank">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><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></blockquote><br>
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></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>dns-operations mailing list</span><br><span><a href="javascript:_e(%7B%7D,'cvml','dns-operations@lists.dns-oarc.net');" target="_blank">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></div></blockquote></div></blockquote></div><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></div></div></blockquote></span></body></html>