In message <cah1iciomwsnu-atbsbdjneka5m+mwwsooll5mnqrme+swtk...@mail.gmail.com> , Brian Dickson writes: > 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. > > > > Configure another recursive server to forward its queries to this > > server and enable validation. > > > > > I believe this is an erroneous configuration. > > You need to have the recursive server (the first one) forward to another > server for the empty zone, otherwise that zone's contents do not end up in > the recursive server's cache.
No you don't. The DS query for ALT needs to be answered from the root zone. This can still be done with default empty zones in play. The below is for 10.in-addr.arpa as I can't be bothered with configuring a ALT zone but it shows that it works with shipping code. I run lots of experimental code but not in this area. % dig ds 10.in-addr.arpa +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2471 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: ba4fd3e10ed3b4972daf8a53589a50ba29889ab19d1a982d (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 10.in-addr.arpa. 3594 IN RRSIG NSEC 8 3 3600 20170226113733 20170205111120 4341 in-addr.arpa. im4xV0dDtx/ccyflDHOwta5h5hLslomiR4JRHynxSE0Tlm4DenVQ2t7B hwWVGE1eoNuVsagkDiYnRykkQX4bQCChsqKKWTVL57f3onXBmiTWXgWI Ruqzo3Oxa3jlbQ2dgO9bF/xpFrJ3/F7BTyoifA7h33dH1Ef1u2OW3p5p kfvR90s= 10.in-addr.arpa. 3594 IN NSEC 100.in-addr.arpa. NS RRSIG NSEC in-addr.arpa. 3594 IN SOA b.in-addr-servers.arpa. nstld.iana.org. 2016110943 1800 900 604800 3600 in-addr.arpa. 3594 IN RRSIG SOA 8 2 3600 20170301070658 20170207211120 4341 in-addr.arpa. JPiSzCVosbzqFnGmIY+WpANm7Si3cTrSFnTfl5ODB7YfyyzRb0TYsA1o nqpmUw5fQyWHY0nClNfqMEW2V529wT+FoG38SlQBNePtuZSjl3k3WIps snl/3HCY6ZFEaMvq+VmLm/9JQP9Nl2+o3n3qKUErZMxHjeJOmBq4O7E9 j0RUGAE= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 09:56:58 EST 2017 ;; MSG SIZE rcvd: 528 [rock:~/git/bind9] marka% dig soa 10.in-addr.arpa +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> soa 10.in-addr.arpa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7409 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: ef3c1c716b970b68d635c9d6589a50cceaa7428cb432d7df (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN SOA ;; ANSWER SECTION: 10.in-addr.arpa. 86400 IN SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 09:57:16 EST 2017 ;; MSG SIZE rcvd: 122 [rock:~/git/bind9] marka% Now if I ask with a non recursive query for DS I get the answer from the empty zone. [rock:~/git/bind9] marka% dig ds 10.in-addr.arpa +dnssec +norec ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ds 10.in-addr.arpa +dnssec +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32952 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 330bcb4d5f583a7463a60035589a52444193e9f918ef9905 (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN DS ;; AUTHORITY SECTION: 10.IN-ADDR.ARPA. 86400 IN SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 08 10:03:32 EST 2017 ;; MSG SIZE rcvd: 122 [rock:~/git/bind9] marka% Now if I add a second validating server forwarding to this server I will only see the first two responses. There are lots of corner cases with DNSSEC which this demonstrates but any server that supports DNSSEC will do. This difference in answers is similar to asking with recursive and non recursive queries for the NS records at a delegation point towards a parent server which supports recursion for the client. You get answers from the child (answer) or parent zone (referral) depending on the state of the RD bit. Mark > Once you have that, the other recursive server (added and forwarding to the > first recursive) only gets back the non-leak results. > > Since the first server is always forwarding to the empty zone, it never > queries the root, and never gets the authenticated denial of existence. Brian. Go do the experiment with VALIDATION ON. You can have heaps of different configurations if you are not validating. Once you have validation being performed then there is only one way to do this that doesn't leak names beyond ALT itself. You can't prevent ALT being leaked if there is a validating client. Mark > Brian > > > 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 > > > > --001a113fece2e8a7ce0547f7c7b3 > 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> > Configure another recursive server to forward its queries to this<br> > server and enable validation.<br> > <br></blockquote><div><br></div><div>I believe this is an erroneous configu= > ration.</div><div><br></div><div>You need to have the recursive server (the= > first one) forward to another server for the empty zone, otherwise that zo= > ne's contents do not end up in the recursive server's cache.</div><= > div><br></div><div>Once you have that, the other recursive server (added an= > d forwarding to the first recursive) only gets back the non-leak results.</= > div><div><br></div><div>Since the first server is always forwarding to the = > empty zone, it never queries the root, and never gets the authenticated den= > ial of existence.</div><div><br></div><div>Brian</div><div>=C2=A0</div><blo= > ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= > cc solid;padding-left:1ex"> > 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> > > --001a113fece2e8a7ce0547f7c7b3-- -- 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
