On 27/05/2020 17:40, Eric Orth wrote:
> 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. In traditional DNS, stub resolvers only talk to a limited set of upstream resolvers, and they could learn (and cache) information about their behaviours, in the same way that recursive servers do for authoritative servers. You only need to launch one "multi QTYPE" query at a server to learn whether subsequent queries to that server can take advantage of that feature. Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
