<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:20141128032205.7807624795B3@rock.dv.isc.org" 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="marka@isc.org" photoname="Mark Andrews" 
src="cid:part1.06060702.02070404@redbarn.org" 
name="compose-unknown-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:marka@isc.org" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Mark Andrews</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 7:22 PM</span></font></div></div></div>
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
    <pre wrap="">
</pre>
<blockquote type="cite"><pre wrap="">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.
</pre></blockquote>
    <pre wrap=""><!---->
Given named does sanity checks when apply ixfr deltas and they
actually have been known to trigger, knowing that you have a complete
zone after applying a ixfr would be a good thing.
...
... Whether is is TSIG or these records you are using a
cryptographic hash + a key to ensure that all the glue is correct
and you are trusting the generator of that hash and signer to be
doing the correct thing.  And the key is tied back to a trust anchor
directly or indirectly.</pre>
  </div>
</blockquote>
<br>
<span>is there some reason why an updated sig(0) is not a solution to 
this? </span><br>
<blockquote style="border: 0px none;" 
cite="mid:20141128032205.7807624795B3@rock.dv.isc.org" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
    <pre wrap="">

</pre>
  </div>
</blockquote>
<blockquote style="border: 0px none;" 
cite="mid:20141128032205.7807624795B3@rock.dv.isc.org" type="cite">
  <div style="color: rgb(136, 136, 136); margin-left: 24px; 
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><blockquote
 type="cite"><blockquote type="cite"><pre wrap="">As to whether you iterate or not also depends on the trust anchors
installed, whether the keys are RFC 5011 managed or similar. Having
a managed trust anchor for every zone isn't a be deal.
</pre></blockquote><pre wrap="">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.
</pre></blockquote><pre wrap=""><!---->
and the whole trigger for this discussion was a mixed mode server with
a local copy of the root zone.</pre></div>
</blockquote>
<br>
is there a specification for how mixed-mode servers will validate data 
they don't fetch? as in, you really are making a recommendation for 
zone-level validation that would then permit zone-local data to be used 
in forming responses to recursive queries in a mixed-mode server? i'd 
like to hear the details of that, because while DNSSEC talks about how 
to validate data you receive in queries, it does not talk about how to 
validate data you've received in zone transfers. i argue that it's not a
 trivial exercise, even if an updated sig(0) could be used to validate 
zone transfers. (i remember more than olafur claims to, concerning why 
we don't have zone-level signatures today. it's related to why glue is 
not signed and does not need to be signed, and it comes from security 
theory not dns theory.)<br>
<blockquote style="border: 0px none;" 
cite="mid:20141128032205.7807624795B3@rock.dv.isc.org" type="cite">
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
    <pre wrap="">

As for adding RFC 5011 support for the zones it serves, a authorative
server has all the data it needs to do that as part of its normal
roll of being a authoritative server.  It's only a matter or reading
what it is serving to others.
</pre>
  </div>
</blockquote>
<span style="font-family: monospace;"><br>
i don't think this is true. rfc 5011 assumes that you're starting with a
 known-good TA and that you'll use this to validate subsequent changes 
to that TA. those starting conditions are not in effect on any 
authoritative-only server i have administered.<br>
  <br>
</span>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>