Re: [DNSOP] Batch Multiple Query Packet
Alfred H?nes a...@tr-sys.de wrote: Is there a clear summary somewhere of why multiple concurrent queries do not satisfy this requirement? A slightly irrelevant pedantic correction: The distinguishing idea was to build in some kind of integrity of RRsets using feedback signaling that allows to indicate empty RRsets (nodata indication per RRtype); caches that do not know the entire RRset of an RRtype asked for do not send a partial RRset but indicate that the response does not answer for such RRtype. Partial RRsets are never allowed. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle, Faeroes: North or northeast 5 to 7, occasionally 4 at first, perhaps gale 8 later in Fair Isle. Rough or very rough. Snow then snow showers. Good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 27 Feb 2012 13:35:45 -0500, Hector Santos wrote: I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. 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. Below are a few comments, and pointers to references, to my past, humble contributions to a possible solution for the issue at hands. In response to a draft that suggested a form of A+ query type, which was submitted/refreshed for the Hiroshima IETF meeting, draft-li-dnsext-ipv4-ipv6-02, on 09 Nov 2009 I have submitted a more versatile proposal to the DNSEXT WG's list [1], which was only one possible variant (for brevity) for a RR Group Query (RRGQ) to query for a group of RRtypes with the same QNAME and QCLASS using an EDNS option to indicate the Data RRtypes wanted. The distinguishing idea was to build in some kind of integrity of RRsets using feedback signaling that allows to indicate empty RRsets (nodata indication per RRtype); caches that do not know the entire RRset of an RRtype asked for do not send a partial RRset but indicate that the response does not answer for such RRtype. The initially posted single variant made use of a Pseudo-RRtype as draft-li-dnsext-ipv4-ipv6, but another potential variant of RRGQ that uses a traditiona Data RRtype in the query section (plus the same EDNS option to indicate the desired Data RRtypes) has been explained later, near the end of a follow-up message [2]. Among the possible applications motivating the proposal and mentioned in the thread were DNSBLs and mail policy records (as you mention). This proposal has been discussed on the list during the Hiroshima IETF timeframe (see the thread started with [1], and shortly in the DNSEXT session in Hiroshima. However, unfortunately I never happened to fully write up this idea as an I-D, but Ray Bellis' dnsext-multy-qtypes draft revives it now (with some variation in the encoding of the EDNS option). This solution -- although not perfect or optimally coded in the present DNS protocol (with EDNS) -- might have the potential to find enough traction to allow relatively fast deployment, eased by its property that it has save fallback to traditional behavior with servers that support EDNS0. The obstacle to fast automatic fallback with responders that do not support EDNS0 due to the rule in RFC 2671[bis] that such responders MUST signal FormErr to query messages carrying an EDNS OPT RR -- unlike in the case of unknown EDNS options (that are to be ignored) is likely to be less of a problem now, because the increase in response sizes expected, and corresponding normative requirements to support EDNS0, for IPv6 and DNSSEC, has lead to now widespread support for EDNS0. So stakeholders interested in a tractable solution who do not want to wait for some future dns-ng allowing this (and much more) in some optimal way are invited to chime in and follow up in the discussion of draft-bellis-dnsext-multi-qtypes on the dnsext list! References to ancient messages on RRGQ -- once sent to the late namedroppers list, and now archived in the dnsext list archive: [1] http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html [2] http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html Please follow the entire thread to evaluate the raised point-of-views. Recent messages on multi-qtypes : http://www.ietf.org/mail-archive/web/dnsext/current/msg12398.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12403.html Kind regards, Alfred Hönes. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
the additional section. MX queries already have their kludge, returning A and records. I'm pretty sure MX queries do NOT have a kludge. I don't believe that the additional section is actually used by any servers these days, Really? Caches throw away additional sections even when they're authoritative? I find that rather surprising. Why would it be a productive use of time to add all this new mechanism, rather than fix caches to use the exact same data that they're already getting? I know about cache poisoning, but the logic to deal with it is exactly the same logic you'd have to use to decide which of multiple answers to accept. My personal goal is to improve resolution times for A/ lookups by collecting them into a single query. Perhaps it makes more sense to simply add Yet Another DNS Hack and add a special QTYPE like ANY meaning any address, that is actually well-defined and usable. Add a new RR called AOR that returns both with a field that has flag bits to say which is valid. And, of course, the A and records in the additional section. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On Mar 1, 2012, at 6:08 AM, John R Levine wrote: the additional section. MX queries already have their kludge, returning A and records. I'm pretty sure MX queries do NOT have a kludge. I don't believe that the additional section is actually used by any servers these days, Really? Caches throw away additional sections even when they're authoritative? I find that rather surprising. Why would it be a productive use of time to add all this new mechanism, rather than fix caches to use the exact same data that they're already getting? I know about cache poisoning, but the logic to deal with it is exactly the same logic you'd have to use to decide which of multiple answers to accept. Yes, the logic should be NEVER cache anything you didn't directly ask for, absent DNSSEC validation. Which means you (IMO) MUST throw away non-authoritative information in the additional section, and most resolvers will only even attempt to cache additional records when they are the records associated with the authority section. It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack. Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information. It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context. Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version. My personal goal is to improve resolution times for A/ lookups by collecting them into a single query. Perhaps it makes more sense to simply add Yet Another DNS Hack and add a special QTYPE like ANY meaning any address, that is actually well-defined and usable. Add a new RR called AOR that returns both with a field that has flag bits to say which is valid. And, of course, the A and records in the additional section. Or don't bother. As I mentioned earlier, this is a clear parallelization case, so the only thing you are saving in this optimization is ~100B of traffic, and the latency involved in transmitting an additional 100B through the network. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
John R Levine jo...@taugh.com wrote: the additional section. MX queries already have their kludge, returning A and records. I'm pretty sure MX queries do NOT have a kludge. I don't believe that the additional section is actually used by any servers these days, Really? Caches throw away additional sections even when they're authoritative? I find that rather surprising. It is also not very useful from the MTA point of view, since the MTA can't tell if A or records are missing because they don't exist or there wasn't enough space in the DNS reply etc. So in most cases (especially an IPv6 aware MTA getting no records in reply) the MTA still has to follow up an MX query with more queries to get address records. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: Cyclonic becoming north or northwest 5 or 6, veering east or southeast 4 or 5 later. Slight or moderate, occasionally rough. Occasional rain. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
It is also not very useful from the MTA point of view, since the MTA can't tell if A or records are missing because they don't exist or there wasn't enough space in the DNS reply etc. So in most cases (especially an IPv6 aware MTA getting no records in reply) the MTA still has to follow up an MX query with more queries to get address records. Sounds like an AOR record with flag bits would help there, too, so long as the authoritative server returned it in the addition section. The client asks for the MX, and gets the AOR so it doesn't have to do A or requests separately. Alternate grosse hackque: some way to return an anti-result in the additional section that says there are no records of this type for this name, that can be negative cached. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
John R Levine jo...@taugh.com wrote: Sounds like an AOR record with flag bits would help there, too, so long as the authoritative server returned it in the addition section. The client asks for the MX, and gets the AOR so it doesn't have to do A or requests separately. Doesn't solve the problem, because you can't infer anything about the existence of a record based on it not appearing in an additional section. Alternate grosse hackque: some way to return an anti-result in the additional section that says there are no records of this type for this name, that can be negative cached. That would help. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South-east Iceland: Westerly, backing southerly or southeasterly, 5 to 7, perhaps gale 8 later. Rough or very rough. Wintry showers, occasional rain later. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack. Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information. It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context. Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version. This makes no sense. Assuming you ignore records for which the server isn't authoritative (which we all do since Kashpureff), why wouldn't you use the records in the additional section? Or to put it another way, if you're worried that the authoritative additional records are fake, why aren't the authoritative answer records equally fake? Same server, same authority. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On Mar 1, 2012, at 7:59 AM, John R Levine wrote: It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack. Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information. It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context. Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version. This makes no sense. Assuming you ignore records for which the server isn't authoritative (which we all do since Kashpureff), why wouldn't you use the records in the additional section? Or to put it another way, if you're worried that the authoritative additional records are fake, why aren't the authoritative answer records equally fake? Same server, same authority. Because caching un-asked-for records is what allows race until win: the ability of an attacker implementing blind cache poisoning to keep retrying the attack until successful. If only the requested information is cached, an attacker targeting www.victim.com can only try to poison once per TTL, because after that, the resolver doesn't generate queries. But if ANY sort of authoritatitive or additional information is cached unasked-for and unverified with a second request (INCLUDING the NS RRSET from the authoritative field), the attacker can start with 1.victim.com, with the additional information containing the poisoned record for www.victim.com. If success? Great. If failure? Retry with 2.victim.com and so-on. Even with halfway-decent port randomization, Race Until Win can be a problem: Poison the NS entry for .com on a major resolver using your botnet and, ohh, boy, can an attacker have some fun. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Sounds like an AOR record with flag bits would help there, too, so long as the authoritative server returned it in the addition section. The client asks for the MX, and gets the AOR so it doesn't have to do A or requests separately. Doesn't solve the problem, because you can't infer anything about the existence of a record based on it not appearing in an additional section. Alternate grosse hackque: some way to return an anti-result in the additional section that says there are no records of this type for this name, that can be negative cached. New improved hackque: the AOR record contains two fields, which contain the number of A and records at that name. The server tries to put the A and records in the additional section, if the number of A or records is less than the count, the client knows they were truncated and has to ask for them explicitly, but in most cases won't. The cache is allowed to synthesize a NODATA answer for A or if the AOR value was zero, although I admit that the interaction with DNSSEC could be unpleasant. Of course, the NSEC record also tells you what kind of records are present at a name, so it can equally well synthesize NODATA from that. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY I dropped the toothpaste, said Tom, crestfallenly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
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. If you're adding logic to servers and clients, why couldn't some of that logic listen on a different port? But honestly, I don't see what problem is being solved here. The original motivation was to ask for SPF and TXT records at the same time, rather than sending two queries. You don't need a new version of DNS to handle that, all you need is a kludge in your server that knows that when it gets a query for one, it can return the other in the additional section. MX queries already have their kludge, returning A and records. The meta-reason for doing two queries is that it's still so hard to provision new RR types that people fake them with TXT. If we're going to hack on our DNS software, I'd rather work on that. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Paul, (Possibly my answer belongs on dnsex not dnsop, but oh well.) On Tuesday, 2012-02-28 00:49:36 +, 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 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
Re: [DNSOP] Batch Multiple Query Packet
Hector Santos wrote: 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. That's doable without multiple queries with a QTYPE=NEWTYPE, which matches both NEWTYPE and TXT. However, there is a caching problem as is documented in RFC1035. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
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 ) as additional data for the MX QTYPE. we should have made QTYPE include type A as additional data. we still can. we should have amended QTYPE A to include type 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
Re: [DNSOP] Batch Multiple Query Packet
Just some BotE: Overhead for each DNS datagram (on an Ethernet) is 8 B for the Ethernet Preamble, 14B for the Ethernet header, 20B for the IP header, and 8 bytes for the UDP header, for a total of 50B. Assuming the question is 50B, and the answer is 150B, the overhead saved is Not That Much by coalesing two requests into one packet: you only save 100B of overhead for communicating 400B of data, which IS non zero, but not enough to really worry about. But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called blast) is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/ RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On Feb 28, 2012, at 10:04 AM, Paul Vixie wrote: On 2/28/2012 5:57 PM, Nicholas Weaver wrote: But since if you could coalesce you could do parallel, this savings doesn't help latency much at all: just the transit time for 50B out and 50B back. If anything, parallel will be BETTER on the latency since batching would probably require a coalesced response, while parallel is just that, parallel, so if the first record is more useful, it can be acted on immediately. parallel (what i called blast) is great solution for things that don't run at scale. but the lock-step serialization that we get from the MX approach (where the A/ RRset may be in the additional data section and so we have to wait for the first answer before we ask the second or third question) has a feedback loop effect on rate limiting. it's not as good as tcp windowing but it does tend to avoid WRED in core and edge router egress buffers. all i'm saying is, we have to be careful about too much parallelism since UDP unlike TCP has no windowing of its own. We don't need to be careful on this until you are talking about ~10 KB of data or more in a single transaction with no interactions, because before then TCP has the same dynamics due to the initial window size (with browsers opening 4+ connections!), and this doesn't seem to bother people. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Batch Multiple Query Packet
I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. 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. Technical Background reasoning. With the advent of new protocols, especially those offering a domain policy construct, the TXT record is used as the fastest entry point with the widest support for query resolution. Yet there are (at least were) technical concerns that this not serve to benefit DNS for large scale usage, therefore considerations are giving to include a migration path to use new registration of RR types. This migration path comes with the recognition for a short term overhead of using a dual type query concept and long term hope for the new RR type to become the non-overhead single query satisfying result. The overall issue is two folds: 1) one where publishers may have to redundantly create two records and the DNS resolvers will always have to do a two queries to maximize widest support, and 2) The continued possible dearth of DNS servers (see RFC 3597 Handling of Unknown DNS Resource Record (RR) Types) that do not support unnamed RR types and/or the recursion requirement. If DNS server offered support for a Batch Query of multiple packets under a single call, this may help with the above migration overhead concerns. Is this something worth pursuing as a new I-D for DNS servers? Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
Hector Santos wrote: I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. 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. Having a query requesting multiple RRTYPEs is a bad idea, because only some of the RRTYPEs may be found in cache. But, it's OK to have separate queries for each RRTYPEs in a single packet. Use TCP or try to extend UDP. However, this may help with the above migration overhead concerns. I don't think so. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 2012-02-27, at 19:49, 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. Isn't that really an argument against multiple responses being carried in the same packet, rather than multiple queries? I'll observe that there are exciting amplification opportunities in a world where a single packet could trigger multiple large responses, though :-) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
At 16:55 -0800 2/27/12, Joe Abley wrote: I'll observe that there are exciting amplification opportunities in a world where a single packet could trigger multiple large responses, though :-) Yes, please, let's not. ;) Size amplification is already a problem. And, this would make monitoring extra hard (how many responses were supposed to be sent?) and, well, just try to write the re-assembly code, trying to collect the responses to the original API call. An especially unpleasant place in the afterlife is reserved for whomever enables this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
On 27 Feb 2012, at 18:35, Hector Santos hsan...@isdg.net wrote: I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. It isn't necessary to add protocol support, since you can already send multiple concurrent queries on a single socket. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Batch Multiple Query Packet
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
Re: [DNSOP] Batch Multiple Query Packet
Hello, By single call, do you mean : ? single query packet (holding multiple questions) ? (I think this was part of EDNS1) ? single TCP session ? Where I believe there is no statement that forbids sending multiple, subsequent, queries over a single TCP connection. -- batching multiple queries over a single TCP session is already allowed. Beware ! Some name server implementations have implicit, sometimes configurable, maximum number of queries they accept over a single TCP session. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: 27 February 2012 07:36 PM To: dnsop@ietf.org Subject: [DNSOP] Batch Multiple Query Packet I am interesting to find information about past or possible current interest regarding the support of a Batch single call of multiple query packets. 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. Technical Background reasoning. With the advent of new protocols, especially those offering a domain policy construct, the TXT record is used as the fastest entry point with the widest support for query resolution. Yet there are (at least were) technical concerns that this not serve to benefit DNS for large scale usage, therefore considerations are giving to include a migration path to use new registration of RR types. This migration path comes with the recognition for a short term overhead of using a dual type query concept and long term hope for the new RR type to become the non-overhead single query satisfying result. The overall issue is two folds: 1) one where publishers may have to redundantly create two records and the DNS resolvers will always have to do a two queries to maximize widest support, and 2) The continued possible dearth of DNS servers (see RFC 3597 Handling of Unknown DNS Resource Record (RR) Types) that do not support unnamed RR types and/or the recursion requirement. If DNS server offered support for a Batch Query of multiple packets under a single call, this may help with the above migration overhead concerns. Is this something worth pursuing as a new I-D for DNS servers? Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
