How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver is doing qname minimization?
On Thu, Feb 9, 2017 at 5:48 PM, Mark Andrews <ma...@isc.org> wrote: > > 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
