Re: Beating an Old Horse, but....
Colm MacCárthaigh <[email protected]> Mon, 4 Oct 2010 19:22:25 -0700
| Newsgroups | gmane.network.djbdns |
|---|---|
| Message-ID | <[email protected]> |
--0016364d2a6fe3a49e0491d55493 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 4, 2010 at 7:00 PM, Mark Johnson <[email protected]> wrote: > 2010/10/4 Colm MacC=E1rthaigh <[email protected]> > >> >> A preprocessor wouldn't do. The name-server would need to support EDNS0, >> and the smarts to include DS and RRSIG records correctly. Additionally, = in >> order to support NSEC and NSEC3 there would need to be a lexicographical= ly >> ordered index available - a CDB backend won't do. It's a fairly large >> undertaking. >> > > For those not familiar with the guts of the various RFCs, could you perha= ps > expand on that statement a little? Note that I'm not disagreeing with yo= u, > I just don't understand the details enough to follow from your premise to > your conclusion. > Sure. NSEC and NSEC3 are how DNSSEC may be used to validate the non-existence of a name. If "NXDOMAIN" was merely a zone-signed response, then it would be replay-able against arbitrary names from that zone. An attacker could forge that any name did not exist. So instead a consistent ordering of records is signed. E.g. lets say you have the records; apple.example.com and carrot.example.com. With DNSSEC, you generate a signature that says "apple.example.com andcarrot.example.com exist and are lexicographically adjacent". Then if someone queries for " banana.example.com" at run-time, a record which doesn't exist - and isn't i= n any DB - the server finds the nearest match (in this case the apple/carrot adjacency) and responds with that NSEC signed response. The querier can then infer "I've been told that nothing between apple and carrot exist, therefore banana really does not exist". The response is re-playable against other names that lie between apple and carrot, but that's ok - they don't exist. NSEC3 is more or less the same as the above, except that instead of the plain lexicographic ordering of the names, it's an ordering of hashes of those names. So the name server must hash the name at runtime, and then loo= k that up in its lexicographically ordered index to find the nearest match. For the EDNS0 and DS/RRSIG statements - those are implied by DNSSEC too. DNSSEC uses the DO bit and other EDNS extended rcodes as a signaling mechanism. For practical reasons too DNSSEC responses generally require EDNS0-sized payloads. As for the DS and RRSIG responses - those should be returned to any DNSSEC querier as part of various signed responses. You can see these in action with dig +dnssec . , you can also see that " a.root-servers.net" and "ac." are the first two names in the root zone, and are adjacent. (Incidentally, if none of the above is news to someone, my team is hiring - get in touch!). --=20 Colm --0016364d2a6fe3a49e0491d55493 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, Oct 4, 2010 at 7:00 PM, Mark Joh= nson <span dir=3D"ltr"><<a href=3D"mailto:[email protected]">johnsonm@g= mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 2010/10/4 Colm MacC=E1rthaigh <span dir=3D"ltr"><<a href=3D"mailto:colm@= allcosts.net" target=3D"_blank">[email protected]</a>></span><br><div cl= ass=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail_quote" sty= le=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);pad= ding-left:1ex"> <div><br></div><div>A preprocessor wouldn't do. The name-server would n= eed to support EDNS0, and the smarts to include DS and RRSIG records correc= tly. Additionally, in order to support NSEC and NSEC3 there would need to b= e a lexicographically ordered index available - a CDB backend won't do.= It's a fairly large undertaking.</div> </blockquote></div><div><br>For those not familiar with the guts of the var= ious RFCs, could you perhaps expand on that statement a little?=A0 Note tha= t I'm not disagreeing with you, I just don't understand the details= enough to follow from your premise to your conclusion. =A0 <br> </div></div></blockquote><div><br></div><span class=3D"Apple-style-span" st= yle=3D"font-family: arial, sans-serif; font-size: 13px; border-collapse: co= llapse; ">Sure. =A0NSEC and NSEC3 are how DNSSEC may be used to validate th= e non-existence of a name. If "NXDOMAIN" was merely a zone-signed= response, then it would be replay-able against arbitrary names from that z= one. An attacker could forge that any name did not exist.<div> <br></div><div>So instead a consistent ordering of records is signed. E.g. = lets say you have the records; =A0=A0<a href=3D"http://apple.example.com/" = target=3D"_blank" style=3D"color: rgb(51, 51, 204); ">apple.example.com</a>= =A0and=A0<a href=3D"http://carrot.example.com/" target=3D"_blank" style=3D"= color: rgb(51, 51, 204); ">carrot.example.com</a>. With DNSSEC, you generat= e a signature that says "<a href=3D"http://apple.example.com/" target= =3D"_blank" style=3D"color: rgb(51, 51, 204); ">apple.example.com</a>=A0and= <a href=3D"http://carrot.example.com/" target=3D"_blank" style=3D"color: rg= b(51, 51, 204); ">carrot.example.com</a>=A0exist and are lexicographically = adjacent". Then if someone queries for "<a href=3D"http://banana.= example.com/" target=3D"_blank" style=3D"color: rgb(51, 51, 204); ">banana.= example.com</a>" at run-time, a record which doesn't exist - and i= sn't in any DB - the server finds the nearest match (in this case the a= pple/carrot adjacency) and responds with that NSEC signed response.=A0<br> <br></div><div>The querier can then infer "I've been told that not= hing between apple and carrot exist, therefore banana really does not exist= ". The response is re-playable against other names that lie between ap= ple and carrot, but that's ok - they don't exist.=A0<br clear=3D"al= l"> <br></div><div>NSEC3 is more or less the same as the above, except that ins= tead of the plain lexicographic ordering of the names, it's an ordering= of hashes of those names. So the name server must hash the name at runtime= , and then look that up in its lexicographically ordered index to find the = nearest match.=A0</div> <div><br></div><div>For the EDNS0 and DS/RRSIG statements - those are impli= ed by DNSSEC too. DNSSEC uses the DO bit and other EDNS extended rcodes as = a signaling mechanism. For practical reasons too DNSSEC responses generally= require EDNS0-sized payloads. As for the DS and RRSIG responses - those sh= ould be returned to any DNSSEC querier as part of various signed responses.= You can see these in action with=A0dig +dnssec =A0. , you can also see tha= t "<a href=3D"http://a.root-servers.net/" target=3D"_blank" style=3D"c= olor: rgb(51, 51, 204); ">a.root-servers.net</a>" and "ac." = are the first two names in the root zone, and are adjacent.=A0</div> <div><br></div></span><div><span class=3D"Apple-style-span" style=3D"font-f= amily: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">(In= cidentally, if none of the above is news to someone, my team is hiring - ge= t in touch!).=A0</span>=A0</div> </div><br>-- <br>Colm<br> --0016364d2a6fe3a49e0491d55493--