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
