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

[Shumon Huque <[e-mail]>]

On Wed, Mar 11, 2015 at 12:02 PM, 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:
>
> > > 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.
>

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


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

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

> This suggested workaround doesn't help with all forms of broken
> > servers.
>
> 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.