Subject: [DNSOP] comments on dnsop-qname-minimisation-02

From: Shumon Huque <[email-masked]>
Date: Wed, 11 Mar 2015 00:35:29 -0400

Hi Stephane,

Some comments on this draft:

>              DNS query name minimisation to improve privacy
>                  draft-ietf-dnsop-qname-minimisation-02
>
> Abstract
>
>    This document describes one of the techniques that could be used to
>    improve DNS privacy (see [[17]I-D.ietf-dprive-problem-statement]), a
>    technique called "qname minimisation".

I think we should fully spell out the term at first occurence, with
the abbreviated form in parentheses:

  technique called "query name minimisation" (or "qname minimisation").

Are we standardizing on the british spelling of "minimisation" in
preference to the americanized "minimization"? Note that RFC6973 (which
this draft references) uses the spelling "minimization".

> [50]1.  Introduction and background
>
>    The problem statement is exposed in
>    [[51]I-D.ietf-dprive-problem-statement] TODO: add a reference to the

I'd prefer the simpler "The problem statement is described in ..".
The term "exposed" in my mind carries a more sensational connotation,
but I might be nitpicking.

> [53]2.  Qname minimisation
>
>    The idea is to minimise the amount of data sent from the DNS
>    resolver.

I'd be more specific about the nature of the data being minimized,
e.g.

"The idea is to minimize the form of the query name sent by the
resolver, by including only the minimum number of rightmost labels
needed in outbound queries to authoritative servers. Additional
labels are prepended to the query name for subsequent queries as
responses and referrals are obtained."

> Under current practice, when a resolver receives the query
>    "What is the AAAA record for www.example.com?", it sends to the root
>    (assuming a cold resolver, whose cache is empty) the very same
>    question.

"Under current practice" implies a description of what is currently
being done before this new resolution method is introduced. When in
fact this paragraph is describing the new method. I suggest replacing
"Under current practice" with "One possible approach to minimized
query names is the following:"

>    To do such minimisation, the resolver needs to know the zone cut
>    [[54]RFC2181].  Zone cuts do not necessarily exist at every label
>    boundary.  If we take the name www.foo.bar.example, it is possible

This makes it sound like minimisation requires a resolver to apriori
know the zone cuts. This is not necessarily correct. A resolver can
learn the zone cuts in the process of adding labels and doing normal
iterative resolution.

One thing this document doesn't make clear is that the algorithm
being presented not only minimizes the query name, but also hides
the query type until it reaches the target zone (by using the NS
query type rather than the actual type). A pure query name minimization
algorithm can just strip off labels and issue normal queries with
the requested query type. I've implemented the latter algorithm
and it works fine (with well behaved authoritative servers). I agree
with the goal of additionally providing privacy for the query type,
but the document should explicitly state that, very early on. The
term 'qname minimization' also doesn't include in it the idea of
qtype hiding, but I don't have a suggestion for a better term.

>    the full qname to the authoritative name server is a tradition, not a
>    protocol requirement.  This tradition comes[mockapetris-history] from
>    a desire to optimize the number of requests, when the same name
>    server is authoritative for many zones in a given name (something
>    which was more common in the old days, where the same name servers
>    served .com and the root) or when the same name server is both
>    recursive and authoritative (something which is strongly discouraged
>    now).

For the statement about mixed mode servers being "strongly discouraged",
is there (1) a useful reference that can be provided, and (2) is there
wide agreement with the statement? I recently heard Mr Mockapetris
himself disagree with the deprecation of mixed mode servers. For the
record, I generally prefer to keep these components separate, but for
operational reasons, rather than a specific reason dictated by needs
of the DNS protocol.

> [61]3.  Operational considerations
>
>    The administrators of the forwarders, and of the authoritative name
>    servers, will get less data, which will reduce the utility of the
>    statistics they can produce (such as the percentage of the various
>    qtypes).

This should more precisely define which types of forwarders will get
less data. I think you mean the forwarders upstream of the resolver
performing qname minimization, rather than forwarders that might exist
between the client and the minimizing resolver.

>    On the other hand, it may decrease their legal
>    responsibility in some jurisdictions.  (TODO: do we keep any mention
>    of legal issues?  We're not lawyers.)

I'd strike the mention of legal issues.

>    Another way to deal with such broken name servers would be to try
>    with A requests (A being chosen because it is the most common and
>    hence a qtype which will be always accepted, while a qtype NS may
>    ruffle the feathers of some middleboxes).  Instead of querying name
>    servers with a query "NS example.com", we could use "A _.example.com"
>    and see if we get a referral.

This suggested workaround doesn't help with all forms of broken servers.
For example, those that return NXDOMAIN or REFUSED at empty non-terminals,
regardless of the query-type. I've catalogued a few of these in some
testing I did earlier this year. I've spoken to two of the big CDNs
that have some of these issues, and they've confirmed that they plan to
fix this behavior. I'm confident that they will before qname minimization
gets widely deployed, but there are a number of other less well known DNS
services that exhibit similar problematic behavior, and a larger discussion
of the operational challenges involved might be useful. Fox NXDOMAIN/ENT
servers, those will essentially be unresolvable to minimizing resolvers,
unless they implement gross hacks like 'ignore NXDOMAIN, prepend another
label, and requery'. This could in turn open those resolvers up to easy
denial of service attacks.

>    Other strange and illegal practices may pose a problem: there is a
>    common DNS anti-pattern used by low-end web hosters that also do DNS

I agree with others: replace 'illegal' with another term ("behavior
that violates the DNS protocol"?)

>    Qname minimisation can decrease performance in some cases, for
>    instance for a deep domain name (like
>    www.host.group.department.example.com where
>    host.group.department.example.com is hosted on example.com's name
>    servers).  For such a name, a cold resolver will, depending how qname
>    minimisation is implemented, send more queries.  Once the cache is
>    warm, there will be no difference with a traditional resolver.  A
>    possible solution is to always use the traditional algorithm when the
>    cache is cold and then to move to qname minimisation.  This will
>    decrease the privacy a bit but will guarantee no degradation of
>    performance.

The above paragraph about situations where performance is decreased
should probably be moved into the section just below it titled
'Performance implications". That section can then discuss both the positive
and negative performance issues.

> [64]4.  Performance implications
>
[...]

> [65]5.  Security considerations
[...]
>
>    Qname minimisation offers zero protection against the recursive
>    resolver, which still sees the full request coming from the stub
>    resolver.

s/zero protection/no privacy protection/

> [97]Appendix A.  An algorithm to find the zone cut

This algorithm looks good, but it is more than just an algorithm to find
zone cuts. It also provides the final answer to the original query name
and type. If so, I think I'd rename it to what it is, e.g. "An iterative
resolution algorithm using query name minimization (and query type hiding)".

And providing a clearly marked complete algorithm in this draft will
be much more helpful to implementers.

>       (6) Query for CHILD IN NS using PARENT's name servers.  The
>       response can be:
>
>          (6a) A referral.  Cache the NS RRset from the authority section
>          and go back to step 1.
>
>          (6b) An authoritative answer.  Cache the NS RRset from the
>          answer section and go back to step 1.
>
>          (6c) An NXDOMAIN answer.  Return an NXDOMAIN answer in response
>          to the original query and stop.
>
>          (6d) A NOERROR/NODATA answer.  Cache this negative answer and
>          go back to step 3.

To be crystal clear, for (6d) I'd suggest "An authoritative NOERROR/NODATA"
answer."

Should we specify clearly (6e?) what to do when encountering other types of
responses like REFUSED, NOTIMP, etc? e.g. do we stop and return that
response, or retry other available authority servers. I ask because
this topic has arisen in other threads, but perhaps specification of
the desired behavior belongs in a more general document.

For practical deployability reasons, it might be necessary to spell
out a more detailed algorithm that falls back to the original qtype
if NS queries do not elicit a usable response.

Shumon Huque.

---

From: Bob Harold <[email-masked]>
Date: Wed, 11 Mar 2015 10:43:54 -0400

On Wed, Mar 11, 2015 at 12:35 AM, Shumon Huque <[email-masked]> wrote:

> ...
> ...
> Could I suggest "query minimization" as a term to include both qname and
qtype minimization?
The term might be a little too vague, but what do others think?

---

From: Shumon Huque <[email-masked]>
Date: Wed, 11 Mar 2015 11:39:30 -0400

> The term might be a little too vague, but what do others think?
I had also thought of 'query minimization', but I think that it risks being
misinterpreted as minimization of the number of queries, so it might not be
better.

Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Mar 2015 17:02:58 +0100

On Wed, Mar 11, 2015 at 12:35:29AM -0400,
 Shumon Huque <[email-masked]> wrote 
 a message of 400 lines which said:

> preference to the americanized "minimization"?

Bikeshedding is postponed until Working Group Last Call :-)

> but I might be nitpicking.

Advice from english writers here?

> responses and referrals are obtained."

Rigorous but may be too long and convoluted?

> fact this paragraph is describing the new method.

No, not at all. It describes the current practice. Under the new
(qname minimisation), the resolver would send only "com" to the root.

> learn the zone cuts in the process of adding labels and doing normal

Yes, it is explained later.

> query type rather than the actual type).

Do note the use of NS is not mandatory. See section 3, the paragraph
starting with "Another way to deal with such broken name servers"
(which you mention later) and also section 3, 1st paragraph about the
statistics of qtypes.

> between the client and the minimizing resolver.

They are not typically called forwarders (see the discussion about
draft-hoffman-dns-terminology)

> This suggested workaround doesn't help with all forms of broken

Nothing deals with all the brokenness found on the Internet.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2015 09:50:07 -0700

> Bikeshedding is postponed until Working Group Last Call :-)

Or beyond. The RFC Editor allows both types of spelling, and they will make it consistent.

> Advice from english writers here?

+1 to Shumon: "exposed" is more sensational, and not appropriate here.

> Rigorous but may be too long and convoluted?

I prefer rigor, and it is not convoluted.

> (qname minimisation), the resolver would send only "com" to the root.

+1 to Stephane here.

> Yes, it is explained later.

It would be better to say "as described later" right after the reference to RFC 2181 so that the reader doesn't think "therefore I can't do this". We want the document to not only describe the practice, but also to encourage it.

> (which you mention later) and also section 3, 1st paragraph about the

My strong preference is that this document only deal with qname minimization. If someone wants to extend that to qtype minimization, which covers a different threat model, that should be done in a different document. 

> draft-hoffman-dns-terminology)

Different thread. :-)

> Nothing deals with all the brokenness found on the Internet.

+1, and unnecessary to state.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Wed, 11 Mar 2015 13:55:19 -0400

> (qname minimisation), the resolver would send only "com" to the root.

Ah yes, you are of course correct. I completely misread the first sentence
in that paragraph, and will be scheduling an eye appointment shortly :-)

> draft-hoffman-dns-terminology)

Hmm, ok. I'm not sure I agree fully with the descriptions in that draft,
but I
see that Paul has admonished us to take it to the appropriate thread, so
I'll defer this

> Nothing deals with all the brokenness found on the Internet.

Yes, I didn't mean to suggest that the document try to address that all
encompassing scenario either :-)

Bad wording on my part. What I wanted to say is that the suggested
workaround doesn't deal with a common form of brokenness which I
then describe in the rest of the paragraph. I think this document needs
to describe common problems for which either workarounds might be
needed in the resolution algorithm, or effort might be needed to proactively
address the brokenness. Otherwise we might end up standardizing a
protocol that doesn't actually work in the field.

Shumon Huque.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 11 Mar 2015 14:02:27 -0400

> Or beyond. The RFC Editor allows both types of spelling, and they will

Okay, that's fair!

> My strong preference is that this document only deal with qname
> minimization. If someone wants to extend that to qtype minimization, which
> covers a different threat model, that should be done in a different
> document.
>

I'm not yet fully decided on this, but I think I'm leaning in Paul's
direction. By deferring
the qtype hiding feature, we have a simpler resolution algorithm & smaller
changes to
existing code. And perhaps more importantly, we have easier deployability -
we don't
have to implement a specific set of workarounds for known problems such as
authority
servers not responding to NS queries, or middleboxes that don't allow them.
And we save
the wasted time & cycles involved in executing those workarounds.

Shumon Huque

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 12 Mar 2015 11:14:18 +0000

On Wed, 11 Mar 2015 16:50:07 +0000,
> +1 to Shumon: "exposed" is more sensational, and not appropriate here.

  Indeed, "exposed" is inappropriate; so is "described".

  Reference to _describing_ the problem statement (perhaps as
  "elegant" or "clumsy"; "long-winded" or "concise") isn't what's
  needed here.

  I suggest any one of "presented", "declared", or "specified".

  ATB
  Niall O'Reilly

---

From: Shumon Huque <[email-masked]>
Date: Thu, 12 Mar 2015 07:38:41 -0400

>   "elegant" or "clumsy"; "long-winded" or "concise") isn't what's

Good point.

>   I suggest any one of "presented", "declared", or "specified".
I like 'specified' best. We should use that.

I'm neutral about 'presented'.

And I don't like 'declared', which sounds like an authoritarian decree
handed down by the high priests of protocol development!

Shumon Huque