Re: [dns-privacy] [[e-mail]: I-D Action: draft-bortzmeyer-dns-qname-minimisation-00.txt]

[Stephane Bortzmeyer <[e-mail]>]

On Thu, Mar 20, 2014 at 11:04:13AM +0000,
 Tony Finch <[e-mail]> wrote 
 a message of 65 lines which said:

> You say "[RFC2181] suggests an algorithm to find the zone cut" but
> although it describes what a zone cut looks like I can't see any
> clear description of an algorithm for finding them.

The wording in my draft is not perfect. Indeed, DNS RFCs rarely
describe algorithms, probably to let some freedom to the
implementations.

>    Another note is that the answer to the NS query, unlike the referral
>    sent when the question is a full qname, is in the Answer section, not
>    in the Authoritative section.

Also a poor wording since it is the Authority section, not the
Authoritative one. (Which, by the way, answers your concern.)

> This goes back to subtleties in the algorithm :-)

Following the general principle of DNS RFCs, I do not think it would
be wise to specify an algorithm for resolution with qname
minimisation, since there is none for traditional resolution.

>   fr          IN NS ?
>   ratp.fr     IN NS ?
>   www.ratp.fr IN NS ?
>   www.ratp.fr IN A ?
>   www.ratp.fr IN AAAA ?

You did not mention the zone which will receive the queries. The third
query will work, even with the broken Alteon load balancers, since it
will be sent to the NS of ratp.fr.

> Or should you skip the third query?

It MAY (RFC 2119) be skipped since a zone cut is not possible because
there is just one label more than the previous name.

> Skipping the third query would improve latency in most cases (when
> there isn't a zone cut at the leaf), but it leads to leakage. For
> example, consider a domain like google.com: do you want the .com
> name servers to know if you are sending mail to Google, rather than
> just looking at their web site?

I do not understand. Do you refer to gmail.com/google.com? If so,
indeed, a resolver has no way of knowing that the two domains are
related and so leakage will occur. If you refer to
mail.google.com/www.google.com, then, assuming mail.google.com is
subdelegated, the list of queries for "A mail.google.com" will be:

(to .) NS com.
(to com.) NS google.com
OPTIONAL (to google.com) NS mail.google.com
(to google.com or to mail.google.com) A mail.google.com

And then for "A www.google.com":

OPTIONAL (to google.com) NS www.google.com
(to google.com or to www.google.com) A www.google.com

I see no leakage. Of course, the DNSmaster of google.com will learn
things but there is no way to avoid that.