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

[Paul Hoffman <[e-mail]>]

On Mar 11, 2015, at 9:02 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> 
> On Wed, Mar 11, 2015 at 12:35:29AM -0400,
> Shumon Huque <[e-mail]> wrote 
> a message of 400 lines which said:
> 
>> Are we standardizing on the british spelling of "minimisation" in
>> preference to the americanized "minimization"?
> 
> Bikeshedding is postponed until Working Group Last Call :-)

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

>> 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.
> 
> Advice from english writers here?

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

>> "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."
> 
> Rigorous but may be too long and convoluted?

I prefer rigor, and it is not convoluted.

>>> 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.
> 
> No, not at all. It describes the current practice. Under the new
> (qname minimisation), the resolver would send only "com" to the root.

+1 to Stephane here.

>>>   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.
> 
> 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.

> 
>> 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).
> 
> 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.

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. 


>> 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.
> 
> They are not typically called forwarders (see the discussion about
> draft-hoffman-dns-terminology)

Different thread. :-)

>> This suggested workaround doesn't help with all forms of broken
>> servers.
> 
> Nothing deals with all the brokenness found on the Internet.

+1, and unnecessary to state.

--Paul Hoffman