<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:20141128085731.7A2FF2482051@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.03000502.06080009@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">Friday, November
28, 2014 12:57 AM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><pre wrap="">In message <a class="moz-txt-link-rfc2396E" href="mailto:54781F2A.4050009@redbarn.org"><54781F2A.4050009@redbarn.org></a>, Paul Vixie writes:
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Mark Andrews <a class="moz-txt-link-rfc2396E" href="mailto:marka@isc.org"><mailto:marka@isc.org></a>
Thursday, November 27, 2014 7:22 PM
</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></blockquote><pre wrap="">is there some reason why an updated sig(0) is not a solution to this?
</pre></blockquote><pre wrap=""><!---->
SIG(0) is hop by hop. </pre></div>
</blockquote>
<br>
i was responding to your examples. if you want end to end zone
signatures so that a tertiary server can know that the secondary isn't
lying to it, then of course SIG(0) (and TSIG) aren't useful.<br>
<pre wrap="">
</pre>
<blockquote style="border: 0px none;"
cite="mid:20141128085731.7A2FF2482051@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"><pre wrap="">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.
</pre></blockquote><pre wrap=""><!---->
Well the early DNSSEC RFC did have the concept of validating the
zone transfer.</pre></div>
</blockquote>
<br>
i think it's gone from current RFC's for a very good reason.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:20141128085731.7A2FF2482051@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="">As for local zone data being returned to recursive
queries the nameserver is broken if it doesn't do so.</pre>
</div>
</blockquote>
<br>
in this scenario, it's possible that noone is validating the signatures
(or the NSEC's.) this sounds unspecified. can you explain (with
reference to 4034 or 4035, or later work) what you mean by "broken"? i
do not know that the current DNSSEC spec explains what a mixed-mode
server should do about validation. if you do, i hope you will point it
out.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:20141128085731.7A2FF2482051@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 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></blockquote><pre wrap="">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.
</pre></blockquote><pre wrap=""><!---->
So what? Do you think a adminstrator is incapable of adding a
trusted key along with the masters to transfer from when configuring
a slave?
zone "." {
type slave;
managed-trusted-key ....;
.....
};</pre></div>
</blockquote>
<br>
i thought you said "has all the data it needs", not "it could be given
all the data it needs".<span style="font-family: monospace;"> let's talk
about how the transition to "managed-trusted-key" would work.<br>
<br>
since we're talking about RFC 5011 here, which covers any zone's TA not
just the root zone's TA, the initial key would have to either be entered
as configuration data, or fetched and validated against an ancestor TA.
in the later case, the authority server would be acting as a validating
stub resolver for the purpose of fetching and validating its way
down-chain from the TA it has (presumably the root pubkey) to the TA
it's establishing.<br>
<br>
i don't view those as trivial steps, but i agree with what i think you
said, which was that if we could maintain each secondary zone's TA
reliably, and we could validate every AXFR and IXFR we receive, then we
could mix local authority data into RD=1 responses in a mixed mode
server. i fear that this would make DNSSEC more fragile for the public
internet, but it sounds like it could at least be made to work in the
lab.<br>
<br>
</span>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>