DNS Query Name Minimisation to Improve Privacy
draft-ietf-dnsop-qname-minimisation-09

[Ballot comment]
First time I see this.

  This tradition comes [mockapetris-history]
  from a desire to optimize the number of requests

[mockapetris-history]
              Mockapetris, P., "Private discussion", January 2015.


Weird, but I guess it's OK...

[Ballot comment]
This seems like a well thought out idea.

I concur with Alvaro's comment about the nature of the experiment, and most of Barry's comments about removing invective. (To which I add "low-end web hosters").

[Ballot comment]
I concur with Alvaro's comment about the nature of the experiment, and most of Barry's comments about removing invective. (To which I add "low-end web hosters")

[Ballot comment]
I like the general approach here.  I agree with Alvaro that it'd be good to be clearer about what the experiment is -- for the purpose of knowing when it's been satisfied and when we can consider having this a standard or a BCP.

I found the document to be a difficult read because of the language.  I'll try to suggest things that I think will improve some places, but, in general, the RFC Editor will have to do a lot of editing.

The Introduction is a bit abrupt, and starts out by giving an over-broad pointer to the dprive problem statement (and using an odd word: exposed).  I suggest this opening instead:

OLD
  The problem statement is exposed in [RFC7626].  The terminology
  ("QNAME", "resolver", etc) is also defined in this companion
  document.  This specific solution is not intended to fully solve the
  DNS privacy problem; instead, it should be viewed as one tool amongst
  many.

NEW
  QNAME minimisation attempts to address one aspect of the general
  DNS privacy problem [RFC7626], and should be considered as one tool
  among many that will address different aspects.  Some terminology
  used herein ("QNAME", "resolver", etc) is also defined in the
  problem statement document.

END

The "it" in the next sentence ("It follows the principle") should probably also be replaced by "QNAME minimisation"; the sentence is otherwise unclear.

-- Section 3 --

  For instance, some authoritative name servers embedded in load
  balancers reply properly to A queries but send REFUSED to NS queries.
  This behaviour is a gross protocol violation, and there is no need to
  stop improving the DNS because of such brokenness.

We do better when we avoid this kind of invective in our standards specs, and when we support statements with references.  I suggest eliminating the words "gross" and "brokenness", and to instead include a reference to a section of a specification that says why this behaviour is incorrect.  Like this:

NEW
  For instance, some authoritative name servers embedded in load
  balancers reply properly to A queries but send REFUSED to NS queries.
  This behaviour violates the DNS protocol (see Section ??? of [RFC??],
  and improvements to the DNS are impeded if we accept such behaviour
  as normal.
END

  Another way to deal with such broken name servers would be to try
  with QTYPE=A requests

Again: please lose "broken" and try to describe things more calmly.  And "to try with QTYPE=A requests"... to try *what* with QTYPE=A requests?  "Try" seems to want a direct object here, and I don't see one.

  See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad
  consequences of this brokenness.

Again: "brokenness"...

  Other strange and non-conformant practices may pose a problem:

"Other practices that do not conform to the DNS protocol standards may also pose problems."

  there
  is a common DNS anti-pattern

Is "anti-pattern" a common term that I'm just not familiar with?  That's likely, of course.  But if not, please replace it.  And probably remove "serious" later in the sentence.

  (It is not known why they don't just wildcard all of "*." and be done
  with it.)

What's the point of this sentence?  Can't it just be removed?  We really shouldn't write standards that sound like rants... please.

  This lets them turn up many web hosting customers without having to
  configure thousands of individual zones on their nameservers.

What does "turn up" mean here?

-- Section 6 --

  However, it may have other advantages.

I suggest changing "However, it may have" to "It may also have", to give this a more positive tone.

  Thus in this common case the total number of upstream
  queries under QNAME minimisation would be counter-intuitively less
  than the number of queries under the traditional iteration (as
  described in the DNS standard).

I think changing "be counter-intuitively" to "actually be" works much better here.

[Ballot comment]
What is the purpose of the experiment? 

As explained in the text, the implementation is a unilateral change…do you want to experiment on the impact of the algorithm in the document, on comparing multiple algorithms (how much they're used, efficiency wrt privacy), etc..  All of the above?  Something else?

[Ballot comment]

Thanks - this looks like it's really really well worked
out. I like the basic idea of course, but the execution
here is very well done.

The secdir review noted some nits you might want to fix
at auth-48. [1]

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06230.html

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-qname-minimisation-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: dnsop@ietf.org, tjw.ietf@gmail.com, joelja@gmail.com, dnsop-chairs@ietf.org, draft-ietf-dnsop-qname-minimisation@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS query name minimisation to improve privacy) to Experimental RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNS query name minimisation to improve privacy'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes one of the techniques that could be used to
  improve DNS privacy, a technique called "QNAME minimisation", where
  the DNS resolver no longer sends the full original QNAME to the
  upstream name server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2469/
  https://datatracker.ietf.org/ipr/2542/

1. Summary

Document Shepherd: Tim Wicinski
Area Director: Joel Jaggeli

This document describes a technique that can improve the privacy of DNS queries by a technique called "QNAME minimalisation" where the DNS resolver no longer sends the full and original query name to the upstream server.

Document Type: Experimental

The document describes a method of altering the current behavior of DNS queries. Limited tests appear that this should not break functionality, but more deployment is needed, as well as working examples.

2. Review and Consensus

The document initially came up during some early discussions around DNS Privacy, which later spawned the DPRIVE working group.  The behavior of minimizing query names (or QNAMES) was not a full solution, but the Working Group felt that the amount of work to make QNAME minimization work was small, that it should be done.

This document was extensively commented on, discussed and approved by a wide breath of the working group.  There was broad consensus, and their was very little controversy.

Explain how actively the document was reviewed and discussed, by the working group and external parties, and explain in a general sense how much of the interested community is behind the document. Explain anything notable about the discussion of the document.

There are no implementations, but several have been discussed.

3. Intellectual Property

There have been 2 IPR disclosures related to this document, both from the same company.
The Working Group discussed the disclosures, and since the patent owners give a royalty-free, reasonable and non-discriminatory license to all implementors; and this is an experimental RFC so there is still questions on deployment; the document could move forward.

4. Other Points

Downward References:  None

IANA Considerations: None