On 28. 05. 20 21:21, Eric Orth wrote: > 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.
I would say it depends on sheer luck: EDNS handling is specified in RFC 2671 from 1999, unknown type handling is in RFC 3597 from 2003. Both should work in 2020. If they don't because resolver vendors does not care. > > 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. Sorry but I think you have unrealistic hopes, probably caused by largely nonexistent auto-disovery of DoH/DoT servers. AFAIK "traditional router vendors" (like AVM, the vendor of FRITZ!box router - mainstream in Germany and countries around) are adding support for DoT and possibly also DoH. Personally I do not see any reason why their resolver available over DoT/DoH should work any better than their unencrypted DNS resolver, which is (at least not in case of AVM) not famous for standards-compliance or performance. Of course vendors are going to reuse whatever they had before, so additional TLS+HTTP layers will just add new bugs on top of whatever bugs they had before. In other words, whole anti-ossification argument seems to hold at the moment only because of missing auto-discovery protocol for encrypted transports. Once we have auto-discovery all the problems will bounce back. Sorry for my grim predictions! > 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. Hmm, shouldn't it be detected at TLS layer? It seems to me that only explotable problem would be if client interpreted connection timeout or TLS errors as missing ESNI RR, which does not sound like a good idea to me. > 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. Interesting... Do you have measurements which suggest that A/AAAA answers have different timing properties? I would expect it mostly depends on whatever is in cache, and if multi-query takes off we can expect both to be present in cache with the same TTL. > *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. I agree - making it mandatory seems like reasonable approch (within certain limits, e.g. answer size etc.). Petr Špaček @ CZ.NIC > > On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <vladimir.cunat+i...@nic.cz > <mailto:vladimir.cunat%2bi...@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
