Paul, (Possibly my answer belongs on dnsex not dnsop, but oh well.)
On Tuesday, 2012-02-28 00:49:36 +0000, Paul Vixie <p...@redbarn.org> wrote: > On 2012-02-28 12:27 AM, Edward Lewis wrote: > > At 13:35 -0500 2/27/12, Hector Santos wrote: > >> If it doesn't already exist or not considered in the past as an > >> unfeasible concept, I am interest in seeing if this is something > >> worth pursuing. > > > > One (not the only, Ohta replied with another) of the oft-cited > > obstacles is the presence of only one RCODE field in the packet. > > (What if one query would be NXDOMAIN and the other has an answer?) > > > > indeed, this is why multiple queries were not supported in the > original DNS, and it's why EDNS doesn't have it either. the number of > signalling bits needed to explain what went on with the multiple > queries made folks' heads explode. the logic is still online if you > want to see it: <http://nsa.vix.com/~vixie/edns1.txt>. I think we're missing a potential great opportunity here by thinking too small. Rather than mucking about with QDCOUNT and breaking old servers, why not just move additional queries into EDNS(n)? So, the idea is to support additional queries by effectively encapsulating them safely into the EDNS space. Basically, you say "here is my question, and if you know the multiple-query DNS extension then please give me those answers too". So for old servers they treat it as an old-style question, and get old-style answers. New servers will give additional information. So on the query side you'd need a field with the "real" QCOUNT, and then a set of additional QNAME/QTYPE/QCLASS entries, possibly like the normal question section, although we can also consider optimizing this a bit by requiring the same QCLASS for all questions for example. Here's the big win I think... On the answer side, you actually don't need to preserve existing DNS format at all. This is because the server knows that the client supports this wacky new multi-question format. That means that we can design a packet format that ACTUALLY MAKES SENSE!!! Consider the possibilities there! We can eliminate the ridiculous waste of 16-bit fields that only ever use one value; we can align the packet so that the variable length data always comes at the end; we can put a massive nonce in; and so on. I don't think this solves with my personal pet peeve (the need to send concurrent A and AAAA queries), but it does provide a necessary piece of the solution. -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
