<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF">summary: no worries, this 
isn't what i thought it was. details below.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.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="warren@kumari.net" photoname="Warren Kumari" 
src="cid:part1.07030602.05090000@redbarn.org" name="postbox-contact.jpg"
 width="25px" height="25px"></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:warren@kumari.net" 
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 2:20 PM</span></font></div></div></div>
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><br>This 
allows a slave (or anyone else who wants to validate a zone, e.g a 
master loading from disk) to know that they have a full and correct 
zone. This covers things like accidental zone truncation (which has 
bitten some folk),</div>
</blockquote>
<br>
if your master server sends you a final (matching) SOA not having 
stuffed its end of the tcp session with all the right records in 
between, or if your TCP is allowing end-to-end badness without its CRC32
 detecting same at the tcp segment level, then you have bigger worries.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.com"
 type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"> zone file
 corruption, etc. if someone hands me a zone somehow (e.g AXFR) and asks
 me to serve it I'd like a way to make sure it hasn't been accidentally 
(or intentionally) changed.</div>
</blockquote>
<br>
for a dnssec signed zone the only way to do that is to zone-walk and 
validate. belt-and-suspenders isn't a good model for axfr/ixfr, because 
complexity, and because the zone signature would have to be 
incrementally maleable and so not one-way or crypto-authentic, because 
update.<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:CAHw9_i+NP5=qt_3Ev3s6xonp1-nOuU24O48k4W_F=PR7pyGcgg@mail.gmail.com"
 type="cite">
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"> I'm assuming I'd want my name 
server software to refuse to load the zone and try retransfer, throw an 
error, or similar.
    <div>The signature could be (and the way I'd envisioned it) DNSSEC, 
so up to a TA, or a manually configured key specific to the zone.<br></div>
  </div>
</blockquote>
<br>
if this is proposed and adopted, my discussion input will be along the 
lines of "no authority server can every be required to query for 
anything as part of its operations". just letting you know where "DNSSEC
 ... signature" leads to.<br>
<br>
importantly, you're envisioning this as a new way to fail, but not a new
 criteria for success. that is, this new signature mechanism is to you a
 reason to reject an AXFR or IXFR, which would then lead to zone timeout
 and SERVFAIL unless corrected. that's not a problem. i was worried that
 this would be used in some way to permit/deny zone data to be used by a
 mixed-mode server in response to RD=1 queries. that would be a larger 
kettle of different fish.<br>
<br>
furthermore:<br>
<br>
> Mark Andrews<br>
> Thursday, November 27, 2014 2:45 PM<br>
><br>
> Just having a cryptographically strong zone self consistancy check<br>
> is a big win with IXFR. If that fails you AXFR the zone and try<br>
> again.<br>
<br>
if you're trying to make a case for public key TSIG, i'd agree with you,
 and say, SIG(0) [RFC 2931]. i'd support an rfc 2931-bis effort, as a 
reviewer and as a contributor.<br>
<br>
> For the root zone you don't need a iterative validator as you would<br>
> have the root as a trust anchor and in general a authoritative<br>
> server needs a interative resolver for NOTIFY.<br>
<br>
if you're arguing that NOTIFY should support DNSSEC by including 
RRSIG(SOA), i'd agree. but right now there is no TA on root zone slaves,
 they never query for anything, they never validate anything, they don't
 speak RFC 5011. and that's a deliberate design decision, not an 
accident or oversight.<br>
<br>
> As to whether you iterate or not also depends on the trust anchors<br>
> installed, whether the keys are RFC 5011 managed or similar. Having<br>
> a managed trust anchor for every zone isn't a be deal.<br>
<br>
adding RFC 5011 support to a non-mixed-mode (authority only) server 
would be a very big deal. so, that's an area of strong disagreement if 
we discuss it further.<br>
<br>
vixie<br>

</body></html>