Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:

>
> In message <[e-mail]>, Ted Lemon
> writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews <[e-mail]> 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: [phone]                 INTERNET: [e-mail]
>