On Wed, May 27, 2020 at 2:34 AM Petr Špaček <[email protected]> wrote:
> On 27. 05. 20 1:05, Paul Vixie wrote: > > so, this way lies madness, and the solution we see most often is a > host-level > > cache of DNS results. the old INN (usenet net news) server had one of > these, > > and all modern browsers have one. many of us simply run a validating > iterative > > caching recursive resolver on our hosts, since it's not much code by > modern > > standards. but in all such cases we don't have a good way to retrieve > more > > than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is > not > > well defined and is broadly unimplemented. various other > multiple-questions > > proposals have been made but nothing gets traction. > > 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). > Maybe a better solution, but considering that the issue I'm dealing with is when the stub is unwilling to send additional queries or queries for new types out of concerns of middlebox ossificiation (especially from older home routers) on additional queries or unknown query types, does anybody have any data to show that the multiple qtype EDNS option won't cause similar issues? But in other cases without as much ossifciation concern, especially when using DoH, I'm supportive of any effort to allow querying multiple types in the same request. Would significantly help with some of the security concerns in ESNI/HTTPSSVC where an attacker could try to block ESNI by identifying and blocking the packets just for the HTTPSSVC records. If A/AAAA/HTTPSSVC are all in the same request/response, you can't block any of it without blocking all of it. My one concern of that specific proposal is that if the client doesn't know that the server will respond for the additional queries, it still has to make separate queries for all three, leading to lots of redundant responses when the additional types are handled. > > I feel that nowadays web browsers have better communication with OS > vendors/stub resolvers (Android and Chrome come to mind). Can we stub > resolvers on board, pretty please? > > -- > Petr Špaček @ CZ.NIC > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
