In message <CAHw9_i+VgYXvQqMgegQRBLgobZ+=00coe+jh2zrfnvc5kbd...@mail.gmail.com> , Warren Kumari writes: > On Wed, Jul 6, 2016 at 6:35 PM, John Heidemann <jo...@isi.edu> wrote: > > On Wed, 06 Jul 2016 12:21:58 -0700, Wes Hardaker wrote: > >>Warren Kumari <war...@kumari.net> writes: > >> > >>> The multiple query example, and multiple TYPEs are interesting, but > >>> solves a different problem > >> > >>Exactly. IMHO, we really need both solutions: > >> > >>1) the ability to ask multiple questions > >>2) the ability for a server to respond with authoritative answers a user > >> will likely ask for next, before it knows what to ask. > > > > Just an observation: > > > > you can do (1) ask multiple questions today with separate queries over > > one TCP connection. Pipeline them and they may even pack down to one > > packet (after connection setup). TCP handles all the edge conditions > > about packet size. (There is some "overhead" in that you get muliple > > DNS headers, but mutliple headers also mean you there is no ambiguity > > about which query the response code applies to.) > > > > Using pipelined TCP does not require protocol changes, but it may > > require implementation changes. (As per RFC-7766.) > > > > TCP perhaps solves the "give me A + AAAA + MX" case. > > > > > > Case (2) is the ability to have a server give back the answers to > > questions you did not yet ask. Isn't that what the "additional" section > > is for? (With or without TCP.) > > Yup, kinda - except that (currently) recursives appear to ignore > "gratuitous" additional records
They also ignore CNAME targets but that doesn't stop people wanting CNAME over SRV. The critical thing is does the recursive server add the additional records or not. The application can then decide whether to use the records or not. A recursive server can also prefetch SRV targets if it has a cache miss if it just doesn't stall the SRV query. > AFAICT[0], currently recursive servers will not trust answers to > questions which have not been asked (and are not required supporting > information (like glue)) -- this was, AFAIK, originally to avoid > things like https://www.cs.columbia.edu/~smb/papers/dnshack.pdf > > Now, with DNSSEC recursive servers have a reason to be able to trust > this data, and so the additional section can be used again for, um, > additional information[1]. > > > W > [0]: Of course, it is entirely possible I'm wrong. I tested this with > some crafted responses (with scapy), but I could have messed up the > testing. > > [1]: Earlier versions of this document called these "ADDitional" > records, but that got too confusing... > > > > > > -John Heidemann > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
