Subject: [DNSOP] I-D Action: draft-ietf-dnsop-qname-minimisation-03.txt

From: [email-masked]
Date: Sun, 07 Jun 2015 09:36:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : DNS query name minimisation to improve privacy
        Author          : Stephane Bortzmeyer
	Filename        : draft-ietf-dnsop-qname-minimisation-03.txt
	Pages           : 11
	Date            : 2015-06-07

Abstract:
   This document describes one of the techniques that could be used to
   improve DNS privacy (see [I-D.ietf-dprive-problem-statement]), a
   technique called "QNAME minimisation", where the DNS resolver no
   longer sends the full original QNAME to the upstream name server.

   REMOVE BEFORE PUBLICATION Discussions of the document should take
   place on the DNSOP working group mailing list [dnsop].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-qname-minimisation-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 7 Jun 2015 18:44:38 +0200

On Sun, Jun 07, 2015 at 09:36:17AM -0700,
 [email-masked] <[email-masked]> wrote 

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-qname-minimisation-03

Since it has been reorganized a lot. Following the consensus in
Dallas, I've streamlined the text, separating specification and
various considerations or comments, and relegating the alternatives to
the main algorithm to appendices.

If you have not yet done so, I recommend reading the storify of the
discussion at the OARC-meeting:
https://storify.com/shuque/qname-minimization-dns-oarc

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Jun 2015 01:54:50 +0100

I like this draft.

I think the penultimate paragraph of section 2 is a bit confusing. I
suggest (starting with the existing text, for context)...

   To do such minimisation, the resolver needs to know the zone cut
   [RFC2181].  Zone cuts do not necessarily exist at every label
   boundary.  If we take the name www.foo.bar.example, it is possible
   that there is a zone cut between "foo" and "bar" but not between
   "bar" and "example".  So, assuming the resolver already knows the
   name servers of .example, when it receives the query "What is the
   AAAA record of www.foo.bar.example",

(new text)

it does not know how many labels it needs to append before it will find
the zone cut. If it uses QNAME minimization, it will guess there is a cut
between "bar" and "example" so it will query the .example name servers for
the NS records for bar.example. It will get a NODATA response, indicating
there is no cut at that point, so it has to to query the .example name
servers again with a longer name.

Without QNAME minimization, it would send the .example nameservers a query
for www.foo.bar.example and immediately get a referral for
foo.bar.example, without the need for more queries to probe for the zone
cut. Section 6 discusses this performance discrepancy further.

(end)

(I can't see anything that describes a way to find a zone cut in RFC 2181
- just, "The existence of a zone cut is indicated in the parent zone by
the existence of NS records specifying the origin of the child zone" which
is less than a suggestion, merely a vague hint that only the clueful will
grok.)

Regarding the last paragraph of section 6, I think the IPv6 reverse DNS is
the best place to find names with lots of labels but few zone cuts. (But
your current example is just like where I work...)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: North or northeast 4 or 5, increasing 6 at times. Slight or moderate.
Occasional thundery rain. Moderate or good.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 11 Jun 2015 19:39:20 -0700

> cut. Section 6 discusses this performance discrepancy further.

I like Tony's new text, and found it easier to follow that the current text. We sometimes forget that people have heard that every dot makes a new level in the DNS and so having a clear explanation of zone cuts as they affect minimization is useful for those who are not normal implementers.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jun 2015 21:30:58 +0200

On Thu, Jun 11, 2015 at 07:39:20PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 41 lines which said:

> We sometimes forget that people have heard that every dot makes a
> new level in the DNS

I don't think it was forgotten here. The current section 2 of -03 (the
text quoted by Tony) clearly says that "Zone cuts do not necessarily
exist at every label boundary"

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jun 2015 21:50:42 +0200

On Fri, Jun 12, 2015 at 01:54:50AM +0100,
 Tony Finch <[email-masked]> wrote 

> (end)

I do not completely agree with the change but I hope I was able to
address your concern. See the diff in
<https://github.com/bortzmeyer/my-IETF-work/commit/ac7615473d448b315da590f0b7f552a44fbb599a>

New text quoted here:

   The minimising resolver works perfectly when it knows the zone cut
   [RFC2181] (section 6).  But zone cuts do not necessarily exist at
   every label boundary.  If we take the name www.foo.bar.example, it is
   possible that there is a zone cut between "foo" and "bar" but not
   between "bar" and "example".  So, assuming the resolver already knows
   the name servers of .example, when it receives the query "What is the
   AAAA record of www.foo.bar.example", it does not always know where
   the zone cut will be.  To find it out, it will query the .example
   name servers for the NS records for bar.example.  It will get a
   NODATA response, indicating there is no zone cut at that point, so it
   has to to query the .example name servers again with one more label,
   and so on.  (Appendix A describes this algorithm in deeper details.)

   Since the information about the zone cuts will be stored in the
   resolver's cache, the performance cost is probably reasonable.
   Section 6 discusses this performance discrepancy further.

> (I can't see anything that describes a way to find a zone cut in RFC

Text deleted.

> Regarding the last paragraph of section 6, I think the IPv6 reverse
> DNS is the best place to find names with lots of labels but few zone
> cuts.

It is indeed mentioned. That's the only real-world example. There are
other in the XML comments of the source file: they were in the text
before but I've been told that using actual domain names for examples
in stable documents like RFC was dangerous (there was a zone cut
between gouv and fr in gouv.fr a few years ago...)