I lead engineering for the stub resolver built into Chrome browser, so while not an OS-level stub, maybe still prominent enough to count for the "any communication" requested above.
My biggest concern with an approach like this is ossification from middleboxes (especially some old home routers) that may not be ideally engineered for the modern web. Chrome has seen significant issues in the past with such middleboxes creating pain (super slow responses mostly) for a small number of our users on sending unusual queries or an increased amount of queries. As such, we're generally afraid of sending out anything other than basic and rate-limited requests when it comes to Classic DNS. Attempting new things and falling back to conservative behavior on an issue is not necessarily a reasonable approach because the middlebox pain is not always limited to the individual queries. In some cases, probing or experimenting with resolver capabilities can cause user pain for all subsequent queries for a period of time on the order of minutes. Since this specific multi-query proposal encodes it in EDNS, it might be more reasonable. I don't have any actual data to back this up, but I would guess that unknown EDNS options are less likely to cause issues than completely unknown queries. So it might be safe enough to at least do super cautious experimentation around it. Note that none of these ossification issues are really a concern with DoH (or DoT) where we can be reasonably sure we're talking to a modern non-ossified resolver. The usefulness of combining queries is a little reduced since DoT and DoH often use connection sharing for multiple requests anyway. But there's still some potential value. In ECH (ESNI) discussions, it has come up a few times that an attacker could try to force a downgrade from ECH by identifying and blocking the larger packets containing HTTPSSVC responses that contain ECH keys but not address resolves. Much safer if A/AAAA and HTTPSSVC can be in the same query/response to force an attacker to block everything or nothing. Additional possible issues with this multi-query proposal: *By combining A and AAAA, you might lose nice abilities to try to speed things up using Happy Eyeballs v2 style algorithms to immediately start using addresses as they come in, before all addresses are received. Not currently a huge issue for Chrome DNS because we don't currently support Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that improvement. *The current proposal seems to give the resolver a lot of leeway to only sometimes include the additional results and includes a TODO note that maybe there should be a way for clients to mark qtypes as mandatory. I don't think the client would get as much use out of multiple qtypes unless it had reasonable confidence that it would at least usually get all the responses. Otherwise, the client is often going to have to make multiple requests in parallel anyway to ensure it can get all the responses reasonably quickly in parallel. Then again, if it's something like requesting an extra qtype that we would be afraid to send in Classic DNS anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more value of just adding in the additional qtype and using the response opportunistically when received. On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote: > Hello. > > On 5/28/20 10:00 AM, Shane Kerr wrote: > > 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'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to implement > on both sides, and other ways that are available. Is saving the number > of IP-layer packets the only significant motivation? > > For resolver-to-auth case I do suspect some potential. Plain UDP will > probably still stay popular there for some time. Though I'm afraid this > might _sometimes_ push the answer sizes too large to fit into one packet > (in signed zones), which in my eyes slightly reduces attractiveness of > the technique, now that we know that UDP over 1.5 kB is no good. > > For non-auth cases, you typically communicate with just one upstream > resolver (or very few), so if the number of packets is a concern, I'd go > for a long-lived TCP or TLS connection (there's e.g. privacy motivation, > too). That's all standardized already, and it naturally avoids those > extra corner cases. Sure, it's probably possible to improve > significantly on session timers and resuming, performance, usage of > Nagle's algorithm, etc. but ATM to me that feels a more worthwhile > investment than any of the multi-answer proposals. One advantage is > that many of the TCP/TLS improvements can be deployed one-sidedly with > some effect but multi-QTYPEs can't. > > --Vladimir > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
