On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote: > One of my colleagues recently brought up the idea of suggesting recursives > add additional HTTPSSVC records into responses for A/AAAA queries as a way > to make HTTPSSVC more available for cases where a stub is hesitant to make > additional queries out of concern for bad behavior from bad middleboxes (a > frequent concern for Chrome when not using DoH). My initial impression is > that it's not a reasonable idea, but I wanted to bring it here to DNSOP in > case anybody has further ideas to make it workable. So any relevant > thoughts or concerns from anybody here?
proposals exist going way back to add AAAA to additional data for answers of type A, and to add A to additional data for answers of type AAAA. this is not different from adding A and AAAA to additional data for answers of MX and SRV, which already happens. your proposal fits the same mold, which is that the spec neither requires nor prohibits it. however, the client API likely does not have a way to benefit from the additional data in a stub response. see getdnsapi.net for a representative example of something that can only tell you answers to the question you asked, even if it knows more, and won't keep the response in state just in case your next question could also be answered by it. getdnsapi has a return_both_v4_and_v6 extension but would need another API change to support HTTPSSVC. for SMTP senders to benefit from the additional AAAA/A data in MX answers, they have to call a lower level API such as res_nsend() and then walk through the response to see what they actually got, in hopes of not needing to make a second query for addresses (or a second and third, if V6 and V4 are available.) 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. > The obvious problems I could think of (all basically along the theme of it > not being ideal when the stub might not even care about HTTPSSVC): > > - Performance implications if the recursive has to retrieve HTTPSSVC or > follow alias chains. Maybe not as bad if only done opportunistically > when the recursive happens to already have everything in cache. > - Polluting DNS for non-browsers. Maybe not as bad if SVCB instead of > HTTPSSVC, but this would likely only be of use for web browsers which are > obviously not the only queryers of A/AAAA. > - Could lead to lots of unnecessary truncation, especially for large > records containing ESNI data. your self-criticisms are all valid in my opinion. however, i think it would be fine to recommend in the HTTPSSVC draft that the necessary subsidiary data like AAAA or A or SVCB all be sent, both in authoritative and non- authoritative responses, when the qtype is HTTPSSVC and the responder knows the additional data (that is, it should not make extra queries to find it just for additional data reasons.) this will push UDP/53 DNS into either TCP/53 DNS (via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or even TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ). long answers are our future. if this data is going to be nec'y to make the primary answer useful, then pre-seeding it is a net good. some day our descendants will break the tyranny of MTU 1500, and thank us for any prework that brought the data their apps needed closer and with fewer round trips. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
