Paul Vixie 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>.
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.
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.
If DNS servers will barf, then never mind. :)
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. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
