On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <CAH1iCip=JKo4-WiMttKDNs3v_8KzP0PTd13KSPtzL6N7pPHWWQ@ > mail.gmail.com> > , Brian Dickson writes: > > --f403045fbba86cf7240547f82103 > > Content-Type: text/plain; charset=UTF-8 > > > > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > > > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > > > writes: > > > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > > > When I validate, I get a secure denial of existence. This is the > > > > correct behavior. Why do you think we would get a SERVFAIL? > > > > > > Because your testing is incomplete. > > > > > > Go add a empty zone (SOA and NS records only) for alt to your > > > recursive server. This is what needs to be done to prevent > > > privacy leaks. > > > > > > > > Here are some possible alternatives (to having the empty zone be named > > "alt."). > > > > First: make the locally served empty zone be "empty.as112.arpa". > > > > Or, second method: have the DNAME RDATA be "alt.empty.as112.arpa", and > the > > locally served zone be the same name. > > Which does not work. If you are serving up a local > > ALT. SOA ... > ALT. NS ... > ALT. DNAME alt.empty.as112.arpa. >
No, I am saying the following: In the root, assume the existence of "ALT. DNAME alt.empty.as112.arpa." Locally, serve your desired content (for what would be reachable below "alt") at: ALT.EMPTY.AS112.ARPA SOA ... ALT.EMPTY.AS112.ARPA NS ... FOO.ALT.EMPTY.AS112.ARPA <RRTYPE> <RDATA> etc The second DNAME would be for convenience only, so your local zone name isn't causing too much confusion. It does not matter one whit what that zone name (as the DNAME RDATA) would be, so long as it is not at or beneath a real global name. Suppose you want to use "foo.x" instead of "foo.alt.empty.as112.arpa": $ORIGIN alt.empty.as112.arpa. foo DNAME foo.x. foo.x. SOA ... foo.x NS ... $ORIGIN foo.x bar TXT "I am bar.foo.x, reachable via bar.foo.alt.empty.as112.arpa or via bar.foo.alt." The first DNAME gets you default protection via the AS112 empty zone, assuming (the generalized you) are not doing local "alt" things. The local service of "alt.empty" over-rides the insecure empty zone, but does not block the validation path down to it. The second DNAME is for convenience only, or potentially for welding some locally served "homenet" onto "homenet.alt". (The latter I am pointing out the feasibility of, not advocating for.) Brian > > then it will not have RRSIG records so it will not validate unless there > is a INSECURE delegation for .ALT. > > I really don't see the point in having the DNAME there other than you > seem to want a DNAME there. > > The public version of the insecure .ALT zone could have a DNAME but > we are not talking about those contents at the moment. We are > talking about what goes into the root zone to make this work. > > > Or, third, have some other name for the zone (anything other than alt, or > > really anything that doesn't collide with a global name), > > Nothing doesn't collide with a global name. This is all about carving > a namespace out of the global namespace. > > > and then use a > > local DNAME from "empty.as112.arpa" (or "alt.empty,as112.arpa") to that > > zone's name (e.g. "homenet" or "homenet.local" or whatever you wish). > > Homenet is still part of the global namespace. Once there is a delegation > and a RFC which states that it is not part of the global namespace then > you have other issues or should we start squatting on the homenet space? > > > Since all of the above occur at or below the transition to unsigned, they > > should validate. (I need to test these, but I don't see why they wouldn't > > work, and all of the above avoid leaking queries to the root or to AS112 > > servers.) > > > > Brian > > > > > > > > > Configure another recursive server to forward its queries to this > > > server and enable validation. > > > > > > Now ask for foo.alt from this second server. > > > > > > Mark > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > > > > --f403045fbba86cf7240547f82103 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > > <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div > class=3D"gmail_quo= > > te">On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews <span > dir=3D"ltr"><<a h= > > ref=3D"mailto:ma...@isc.org"; target=3D"_blank">ma...@isc.org > </a>></span>= > > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 > .8ex;bor= > > der-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div > class= > > =3D"h5"><br> > > In message <<a href=3D"mailto:18F2EB0D-5BD0- > 4CC5-B02C-2E5EA0B8CC23@fugue= > > .com">18F2EB0D-5BD0-4CC5-B02C-<wbr>2e5ea0b8c...@fugue.com</a>>, Ted > Lemo= > > n writes:<br> > > > Hm.=C2=A0 =C2=A0When I look for foo.alt, what I get is NXDOMAIN, > not S= > > ERVFAIL.<br> > > > When I validate, I get a secure denial of existence.=C2=A0 > =C2=A0This = > > is the<br> > > > correct behavior.=C2=A0 =C2=A0Why do you think we would get a > SERVFAIL= > > ?<br> > > <br> > > </div></div>Because your testing is incomplete.<br> > > <br> > > Go add a empty zone (SOA and NS records only) for alt to your<br> > > recursive server.=C2=A0 This is what needs to be done to prevent<br> > > privacy leaks.<br> > > <br></blockquote><div><br></div><div>Here are some possible > alternatives (t= > > o having the empty zone be named "alt.").</div><div>< > br></div><di= > > v>First: make the locally served empty zone be > "empty.as112.arpa"= > > .</div><div><br></div><div>Or, second method: have the DNAME RDATA be > "= > > ;alt.empty.as112.arpa", and the locally served zone be the same > name.<= > > /div><div><br></div><div>Or, third, have some other name for the zone > (anyt= > > hing other than alt, or really anything that doesn't collide with a > glo= > > bal name), and then use a local DNAME from "empty.as112.arpa" > (or= > > "alt.empty,as112.arpa") to that zone's name (e.g. > "home= > > net" or "homenet.local" or whatever =C2=A0you > wish).</div><d= > > iv><br></div><div>Since all of the above occur at or below the > transition t= > > o unsigned, they should validate. (I need to test these, but I don't > se= > > e why they wouldn't work, and all of the above avoid leaking queries > to= > > the root or to AS112 servers.)</div><div><br></div> > <div>Brian</div><div><b= > > r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" > style=3D"margin:= > > 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > Configure another recursive server to forward its queries to this<br> > > server and enable validation.<br> > > <br> > > Now ask for foo.alt from this second server.<br> > > <div class=3D"HOEnZb"><div class=3D"h5"><br> > > Mark<br> > > --<br> > > Mark Andrews, ISC<br> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > > PHONE: <a href=3D"tel:%2B61%202%209871%204742" > value=3D"+61298714742">+61 2= > > 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0INTERNET: <a href=3D"mailto:ma...@isc.org";>ma...@isc.org</a><br> > > </div></div></blockquote></div><br></div></div> > > > > --f403045fbba86cf7240547f82103-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
