Paul, At 2016-07-06 07:34:03 -0700 "Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
> On 6 Jul 2016, at 3:54, Ray Bellis wrote: > > > On 06/07/2016 10:09, fujiw...@jprs.co.jp 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
pgp1qI1FW45IL.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
