Re: [DNSOP] Batch Multiple Query Packet

Alfred H?nes 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 e

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,

Re: [DNSOP] Batch Multiple Query Packet

Ray, On Wednesday, 2012-02-29 10:17:26 +, Ray Bellis wrote: > > On 28 Feb 2012, at 18:40, Paul Vixie wrote: > > 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

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 infe

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'

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 da

Re: [DNSOP] Batch Multiple Query Packet

John R Levine 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 p

Re: [DNSOP] Batch Multiple Query Packet

On Wed, Feb 29, 2012 at 10:22:55AM +0100, Shane Kerr wrote: > Paul, > > On Tuesday, 2012-02-28 18:40:30 +, > Paul Vixie wrote: > > i'd start over with a new port number first. dns wire encoding is > > already wildly complicated. > The main (only?) advantage of doing it with EDNS is that yo

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

Re: [DNSOP] Batch Multiple Query Packet

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 thr

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, >

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

Re: [DNSOP] Batch Multiple Query Packet

John, On Wednesday, 2012-02-29 16:47:16 -, "John Levine" wrote: > >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 D

Re: [DNSOP] Batch Multiple Query Packet

Shane Kerr (shane) writes: > > 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. Would it be nuts to sugggest that the different port could be specified

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

Re: [DNSOP] Batch Multiple Query Packet

On 28 Feb 2012, at 18:40, Paul Vixie wrote: 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

Re: [DNSOP] Batch Multiple Query Packet

Paul, On Tuesday, 2012-02-28 18:40:30 +, Paul Vixie wrote: > > > . > > 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 addit

Re: [DNSOP] Batch Multiple Query Packet

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. > > . > I think we're missing a potential great opportunity here by thinking > too small. > > Rather than muc

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

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

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

Re: [DNSOP] Batch Multiple Query Packet

On 2/28/2012 3:28 AM, Hector Santos wrote: > Paul Vixie wrote: >> ... . > > 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 defa

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 as

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 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 > >> u

Re: [DNSOP] Batch Multiple Query Packet

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

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 anoth

Re: [DNSOP] Batch Multiple Query Packet

On 27 Feb 2012, at 18:35, 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. It isn't necessary to add protocol support, since you can already send multiple concurrent que

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 e

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. >>

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 t

Re: [DNSOP] Batch Multiple Query Packet

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 RCO

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 t

[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.