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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
