On 2/28/2012 3:28 AM, Hector Santos wrote: > Paul Vixie wrote: >> ... <http://nsa.vix.com/~vixie/edns1.txt>. > > Thanks Paul. Great material. > > I'm just winging it at this point. > > First, I was focusing on the batching of related types, i.e. a > protocol with new RR type but has an initial default intro record and > fallback to TXT. The goal is to have a single call that will yield a > managed result to assist with the current concerns and waste > associated with the migration of TXT to the new RR type usage.
the way this was handled for MX was to have A (and later AAAA) as additional data for the MX QTYPE. we should have made QTYPE AAAA include type A as additional data. we still can. we should have amended QTYPE A to include type AAAA as additional data. we still can. using additional data for this is great since if it's missing you query for it but it won't always be missing. > Second, I considered there is no room for a packet count, but I was > thinking of simply bundling two separate packets, i.e. 2*RR for the > UPD send and how would the servers read this. RCODE FORMERR. this means the initiator would have to be prepared to try again with discrete queries. this is a form of protocol negotiation -- the fact of a responder's nonsupport would have to be discovered (and cached "for a while") by each initiator. this is already happening for EDNS. i would recommend against adding more responder state to initiators. this would also mean that when it works you've got one round trip and when it doesn't work you've got either three (assuming you don't blast #2 and #3 without inter-record gap) or two round trips (if you use blast on #2 and #3.) > If DNS servers will barf, then never mind. :) yes. > But if its offers a way to perform this concept with no breakage, > perhaps the server will just read the first one and act on it or it > will process the residual packet as well. Of course, the client will > still need to manage the responses with all the potential delays. > > Again, just winging it. I don't like kludges. :) please consider additional data, or blast. paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
