[DNSOP] Love for draft-bellis-dnsext-multi-qtypes (was The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption")

[Shane Kerr <[e-mail]>]

Paul,

At 2016-07-06 07:34:03 -0700
"Paul Hoffman" <[e-mail]> wrote:

> On 6 Jul 2016, at 3:54, Ray Bellis wrote:
> 
> > On 06/07/2016 10:09, [e-mail] wrote:  
> >> * My idea
> >>
> >>   I prefer multiple query sections (with some restrictions)
> >>   and merged answers.
> >>
> >>   multiple query examples may be
> >>     NAME A + NAME AAAA + MX
> >>     NAME A + NAME AAAA + _443._tcp.NAME TLSA
> >>     NAME A + NAME AAAA + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + 
> >> ...
> >>
> >>   Many people may dislike QDCOUNT != 1.
> >>   EDNS0 option which contain additional query section may be 
> >> possible.  
> >
> > and there's my idea (draft-bellis-dnsext-multi-qtypes-02) which only
> > permits a single QNAME, but supports additional QTYPEs via an EDNS0 
> > option.  
> 
> Of these three solutions to the same problem, I prefer Ray's. It seems 
> less work to implement and less likely to trip up naively-implemented 
> DNS stacks.

I think that I agree.


In either the case of that or Warren's draft, I reiterate that I think
that the biggest win is from the stub to resolver state, where we can
in principle save almost 50% of the queries that the resolver answers.

I think advice to stubs (and possibly resolvers) would help make Ray's
draft more useful.

For stubs the recommendation could be as simple as:

1. When starting, send a query for ID.SERVER or the like with the multi
   QTYPE option (QTCOUNT=0), and look for the QTD bit in the reply.

2. If this works, future queries to the local resolver can use multi
   QTYPES. Should a answer come back without the QTD bit, then the stub
   should immediately stop using multi QTYPES.

For resolvers, the advice probably should be expanded. My thinking is
that a resolver who wants to try this should include the multi QTYPE
option with the first query to an authority server for probing. If a
resolver doesn't know whether a server supports multi QTYPE then it can
go ahead and do queries in parallel the old fashioned way - while
probing. :) (Surely any production server will have to do back-off in
the same way that they do EDNS0 back-off - it seems like this would be
helpful to note in a document, but maybe that is over-specification.)

Cheers,

--
Shane