In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon writes: > > On Feb 9, 2017, at 3:45 PM, Mark Andrews <ma...@isc.org> wrote: > > At the moment we have Ted saying that if you want privacy you MUST > > also turn on DNSSEC validation and implement QNAME minimisation and > > implement agressive negative caching (still a I-D). > > No, I am _not_ saying that. I am saying that an unsigned delegation > doesn't help with privacy unless you also specially configure your local > resolver, and if you are going to specially configure your local > resolver, then there are several options for how to do that. The only > reason you need DNSSEC is that if you specially configure your local > resolver to lie, then DNSSEC validation will break that. If you aren't > doing DNSSEC validation, you can say any old thing in your local resolver > and the stub will believe it.
And a signed answer doesn't help unless the recursive server is validating (so it can trust the NXDOMAIN) and has QNAME minimimistion (to prevent *.alt leaking in the first place) and has agressive negative caching (so the answer from the minimised QNAME query get turned into a answer for *.alt). Now we can put QNAME minimisation into a server. Now we can put the code to support agressive negative caching into a server. We can't force validation to be enabled. We need all three things for the privacy leakage to stop. Any two alone doesn't stop it. The alternative is to do a insecure delegation and build in a default empty zone for alt. You then have to take steps to break the privacy leak by disabling the empty zone. Additionally it works with all existing servers if they just add a empty .alt zone. It doesn't require validation to be enabled. It's the difference between defaulting private or not. 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
