Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

Phillip Hallam-Baker <> Wed, 19 March 2014 19:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37CDE1A06D8 for <>; Wed, 19 Mar 2014 12:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-AJqusESpMd for <>; Wed, 19 Mar 2014 12:27:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22f]) by (Postfix) with ESMTP id 09EC71A045B for <>; Wed, 19 Mar 2014 12:27:13 -0700 (PDT)
Received: by with SMTP id w7so6180325lbi.20 for <>; Wed, 19 Mar 2014 12:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gXUo3HzSguKGyD+nQyvFBZnTB5FlPoeoX5JIkY7ztuU=; b=pdBCSLuTse4SbFQiWCk2Afjqq2NK7XGV21pBRcW4WEiSpFflEQ3OgbDBG0XWiZFR9w ECAQWvuulfHYkCs+WARzgN/kMjgrzL5d7hEaXXHJoT+2ruaPmnDEzLL2pzVPXpHcKawU UEeH2BuEJeZFaBUR4ICO07cYVODDQseCJFF5HiXQ9bKzsxTaMjVJMCkEjWqAJagllNML Av6zJo7SZUfQ9bw0oTXickGRms9zZV0yZBeObhSa8eKGzrL9xU+PQLP0K2Lg1j5efwDT d47fnMGSR34fVSR+IY1Mt7hIEGKhXUOLooQkYm0N8SsPfIrsBut/h7gRhc8LD7srkJ6W Ur6w==
MIME-Version: 1.0
X-Received: by with SMTP id ki20mr2501636lbb.45.1395257224494; Wed, 19 Mar 2014 12:27:04 -0700 (PDT)
Received: by with HTTP; Wed, 19 Mar 2014 12:27:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 19 Mar 2014 15:27:04 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Paul Wouters <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Tony Finch <>,
Subject: Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Mar 2014 19:27:16 -0000

On Wed, Mar 19, 2014 at 2:34 PM, Paul Wouters <> wrote:
> On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:
> [ still finding your replies to replies basiclly unreadable due to your
>   email client quoting settings, so if I'm mis-attributing, thats why.
>   When these go like 3 deep, I basically have to just give up and delete
>   the emails unread. You are the only person I have this problem with,
>   and plenty of people use gmail.]
>> On Wed, Mar 19, 2014 at 2:06 PM, Tony Finch <> wrote:
>>       Phillip Hallam-Baker <> wrote:
>>       >
>>       > In particular, if we let a DNS query ask more than one question at
>> a
>>       > time then we improve latency of responses.
>> No need to change the protocol, just make the queries concurrently. If
>> your implementation makes that slow, fix the implementation. You would
>> have to fix it anyway in order to support the protocol changes, so you
>> might as well do the fix without the protocol change. No need to waste
>> time and money on talking about paper protocols.
>> This is not a change. It is implementing RFC1035 as written.
>> BIND and co have done it wrong all these years. If the implementations are
>> not wrong then where is the RFC that states QDCOUNT = 1?
> We tested this a few months ago while discussing
> draft-wouters-edns-keepalive using
> a modified dig command.
> All servers support multiple queries at once fine. Only google dns
> capped it at 80 queries before closing the connection. Things will be
> different when the TCP connection is idle of course, as the server might
> hang up on you, hence the above mentioned draft to match up client and
> server behaviour.

Wow, so we have the capability there in the infrastructure but people
are saying that they can't check for DANE records or other policy
records and other people are saying that we shouldn't 'change' the

>> I have talked to the engineers at several browser companies and they tell
>> me that parallel queries do not actually work the way you imagine.
> All the more reason for draft-wouters-edns-keepalive (and
> draft-wouters-edns-chain-query)

That looks like a perfectly sensible suggestion. But I would prefer to
avoid going to TCP unless it is absolutely necessary.

If we go to TCP then the shortest distance between two points is to
make DNS a Web Service and run it over TLS. Now I do in fact do
precisely that in OmniBroker to provide a 'last ditch' resolution
service for cases where the user is stuck behind a hotel portal. But I
was hoping to avoid that for DNSE.