On 2/28/2012 9:02 AM, Shane Kerr wrote: > Paul, > > (Possibly my answer belongs on dnsex not dnsop, but oh well.)
i've heard recently that dns is exy. > > <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. i'd start over with a new port number first. dns wire encoding is already wildly complicated. > 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. if the EDNS option for this just had an array of additional QTYPE, such that the real QNAME and QCLASS pertained to all of these additional questions, then i could definitely see value in this. the response's OPT option would include the list of qtypes which were found to be non-empty. all of the rrsets would be in the answer section. > ... > Here's the big win I think... > ... > 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 think we'd slab the rrsets, put the signatures on as metadata to the slabs (having no names of their own), and a lot of other things. it's worth scribbling down what we'd do in the packet format if we could start over, even though i don't think we can start over. paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
