[dns-operations] cool idea regarding root zone inviolability

Fri Nov 28 08:57:31 UTC 2014

In message <54781F2A.4050009 at redbarn.org>, Paul Vixie writes:
> > Mark Andrews <mailto:marka at isc.org>
> > Thursday, November 27, 2014 7:22 PM
> >> 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.
> >
> > 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.
> 
> is there some reason why an updated sig(0) is not a solution to this?

SIG(0) is hop by hop. 

> >>> 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.
> >> 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.
> >
> > and the whole trigger for this discussion was a mixed mode server with
> > a local copy of the root zone.
> 
> 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.

Well the early DNSSEC RFC did have the concept of validating the
zone transfer.  As for local zone data being returned to recursive
queries the nameserver is broken if it doesn't do so.

> 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.)

Really all records should be signed so you reject on reception
rather than after the fact.  Most recursive nameservers won't recover
from spoofed glue if you can manage to insert it which leads to a
DoS.  We detect that we got misdirected.  Improvef hop-by-hop
security however can deal with that or we can add glue signatures
(covers delegating NS, A and AAAA) though it will increase delegation
centric zone sizes and OPTOUT would be pointless.

> > 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.
> 
> 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.

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 ....;
	.....
};

> -- 
> Paul Vixie
> 
> --------------010306050600050904090007
> Content-Type: multipart/related;
>  boundary="------------090301010501070707010608"
> 
> 
> --------------090301010501070707010608
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> <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 at 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 at isc.org" photoname="Mark Andrews" 
> src="cid:part1.06060702.02070404 at 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 at 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 at 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 at 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 o
> r 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 at 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>
> 
> --------------090301010501070707010608
> Content-Type: image/jpeg; x-apple-mail-type=stationery;
>  name="compose-unknown-contact.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <part1.06060702.02070404 at redbarn.org>
> Content-Disposition: inline;
>  filename="compose-unknown-contact.jpg"
> 
> /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC
> AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC
> AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR
> CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK
> BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA
> AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA
> DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ
> VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4
> v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx
> +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR
> UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab
> eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz
> hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi
> yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y
> zqnlfp6FrqbwawG8/9k=
> --------------090301010501070707010608--
> 
> --------------010306050600050904090007--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org