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

Stephane Bortzmeyer <> Thu, 20 March 2014 14:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2304C1A08C3 for <>; Thu, 20 Mar 2014 07:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QrIIwoB9KVDo for <>; Thu, 20 Mar 2014 07:23:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF4071A08B7 for <>; Thu, 20 Mar 2014 07:23:17 -0700 (PDT)
Received: by (Postfix, from userid 10) id A27FD3B89F; Thu, 20 Mar 2014 15:23:06 +0100 (CET)
Received: by (Postfix, from userid 1000) id 5AA71CB91C; Thu, 20 Mar 2014 15:20:20 +0100 (CET)
Date: Thu, 20 Mar 2014 15:20:20 +0100
From: Stephane Bortzmeyer <>
To: Tony Finch <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 7.3
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dns-privacy] [ I-D Action: draft-bortzmeyer-dns-qname-minimisation-00.txt]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Mar 2014 14:23:23 -0000

On Thu, Mar 20, 2014 at 11:04:13AM +0000,
 Tony Finch <> 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

>    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 ?
>     IN NS ?
> IN NS ?
> IN A ?

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

> 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 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 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, then, assuming is
subdelegated, the list of queries for "A" will be:

(to .) NS com.
(to com.) NS
(to or to A

And then for "A":

(to or to A

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