In message <CAH1iCiq0bAiyZU0SqxWn7vH=gbhdhkn78zs-1412dhasffo...@mail.gmail.com> , Brian Dickson writes: > --001a1140fee44d9e500547f98cf1 > Content-Type: text/plain; charset=UTF-8 > > 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."
So how do you get the DNAME returned without leaking a qname? Answer: You don't with current nameservers. To prevent leaking you need to have something that regularly asks for ALT/DNAME so that the answer is in the cache before the first *.alt name comes along or you special case *.alt, make a DNAME query for ALT instead of *.alt then resume the original query processing. That is new code just to avoid a insecure delegation in the root zone when we know we need a insecure delegation in the root zone for .homenet. You also generate bigger answers, run the risk of returning YXDOMAIN and increase the validation cost. There is a place for that DNAME in a insecurely delegated ALT zone. That sinks all the traffic that is not caught by the other mechanism. Mark -- 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
