Paul, On Tuesday, 2012-02-28 18:40:30 +0000, Paul Vixie <p...@redbarn.org> wrote: > > > <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.
Ya think? ;) The main (only?) advantage of doing it with EDNS is that you can work with existing name servers. It means adding more logic to our already fabulously complicated resolvers to get full benefit, but nobody ever said DNS was easy. So possibly the logic would work like this: 1. Send query with the magic EDNS to a server. 2. If the response is in the new format, then remember that. 3. Subsequent queries go to a different port, using a new format. > > 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. I'm curious what use cases you are thinking of, so that you want to restrict the entire collection of questions to a single QNAME/QCLASS. One use case which I can think of which fits in here is the A/AAAA case. You'd need to cache server support for efficient operations, but I think it could be a win. Another use case which fits in is getting both SPF records and legacy TXT records when checking mail from a domain. One use case which does NOT fit in here is to translate all of the servers for an NS RRSET at once. I'd like to be able to say "here are a list of names, give me all of the A and AAAA records for all of them". Anyway, I'm curious. :) > > ... > > 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. If we can make the equivalent of name compression more efficient, I think it could even be something that has enough operational benefit to make it worthwhile for operators. -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
