On 28. 05. 20 10:00, Shane Kerr wrote: > Ray and other DNS operations folks, > > On 27/05/2020 10.30, Ray Bellis wrote: >> >> >> On 27/05/2020 07:33, Petr Špaček wrote: >> >>> I would much rather spent time on >>> https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 >>> >>> That would bring benefit to broader set of clients and has advantage >>> that server does not send back data nobody asked for (thus wasting >>> resources on unnecessary work). >> >> I'd be very happy to revive that work if there's interest. > > As I have mentioned several times on microphone, I think this draft has huge > potential, potentially cutting the number of queries handled by recursive > resolvers almost in half - since they could ask for A and AAAA records in a > single query. > > I wonder what work is left other than implementation?
Most importantly we are missing buy-in (or more precisely _any communication_) with stub resolvers which are actually used by applications. If anyone from Android, iOS, Microsoft, glibc would like to comment here it would be ideal. Personally I: a) Very much like idea of this draft b) At the same time I'm against making this RFC until we have end-to-end implementation. If we do not have implementations on all ends this draft will simply end up as yet another item on my "list of dnsop failures" with drafts published but never implemented, and that's huge waste of everybody's time. > > Possibly it makes sense to describe client how stub or forwarding resolvers > may want to probe their full-service resolvers? I expect that normal behavior > would be: > > 1. Send a query with the Multi-QTYPE option and see if the resolver supports > it. > 2. If it does to send single queries for address lookups instead of parallel > AAAA/A queries. > 3. Fallback to parallel AAAA/A queries as soon as they get a response that > does not support Multiple-QTYPE. > > Similar description for recursive-to-authoritative might be helpful, since > resolvers cache information about authoritative servers. I guess we could > expect resolvers to ask for DNSKEY and NS together when it makes sense, for > example. Yes, certainly... but ideally this should be done in concert with stub resolver developers so they can tell us what they need from the protocol. Most famously glibc resolver might not have sufficient state to cache this information, or ... I don't know. Petr Špaček @ CZ.NIC > Of course, these use cases can be left as an exercise to the implementer. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
