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

Phillip Hallam-Baker <> Fri, 21 March 2014 11:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE71C1A08B7 for <>; Fri, 21 Mar 2014 04:32:59 -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 f-47mv37FA2J for <>; Fri, 21 Mar 2014 04:32:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::233]) by (Postfix) with ESMTP id BA1741A08AE for <>; Fri, 21 Mar 2014 04:32:57 -0700 (PDT)
Received: by with SMTP id pv20so1583620lab.10 for <>; Fri, 21 Mar 2014 04:32:47 -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=Vh1+EGnk6xOdKlkJLfcAIIvoraDXXHceNM4z2jcvJQs=; b=BvsJ5Zbh9ke2ltN+/3QahQEczX3WiB9l5q/6/j4xmwaC8DoMzoBMNbMERVOEXv/D2x 4Nbk1BOBJ6g5M5dKx+HTm0oPVXNNddBe+Jk0aI8V103bYyPeH1sOyM0zFKDiJI4ptJTl 2TKXWFaA6NHjHXGpGwb4Ctm/oJq+pVZSV+CLGjbP4No4CP9q8PAaQopXSq6dfmKbFhjG gJfUR/UyM88UV5qcP9ow1UVNtb37DH21ojQBO2Wc7U3U868M6Sl+3fgvPPGPDEmnH4eK KHnjOeKQOOrCSYsYsN3AJPdOkpTITW4BD+7UihrN8Z8GOi6YxJS5KMPnTLDWwf2OJ6Ok mpRw==
MIME-Version: 1.0
X-Received: by with SMTP id df5mr5470327lbb.36.1395401567834; Fri, 21 Mar 2014 04:32:47 -0700 (PDT)
Received: by with HTTP; Fri, 21 Mar 2014 04:32:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 21 Mar 2014 07:32:47 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Tim Wicinski <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Fri, 21 Mar 2014 11:33:00 -0000

On Fri, Mar 21, 2014 at 12:33 AM, Tim Wicinski <> wrote:
> On 3/20/14, 8:54 AM, Phillip Hallam-Baker wrote:

>> What I am saying here is that we have an opportunity to say that we
>> leave certain parts of the legacy behind without additional cost.
>> Or we could start the work by declaring that the DNS protocols were
>> handed down in a state of grace and that they represent the most
>> shining example of perfection we can hope to achieve and that anyone
>> who suggests the mere possibility of alternative approaches must be
>> cast out as a heretic.
> Or we can do something like HTTP/2 is doing and approaching it as a new
> mechanism and allow methods for choosing, but having a fall back strategy.

That is what I was proposing.

Every time we try to use the DNS for a particular project we end up
hitting our heads against a slew of deployment restrictions that make
it unusable or limit the value.

Encrypting the traffic is inevitably a significant discontinuity.

>> DNSSEC has always had to dance round the problem that DNS responses
>> have to fit in one packet. And that pushes a huge number of
>> contortions onto designs. I think it is more than reasonable to
>> require that if people are going to start encrypting packets that they
>> be required to have a strategy that can transport DNSSEC packets for
>> almost all real world protocols without having to switch from UDP to
>> TCP. That could mean staying in UDP all along or starting in TCP from
>> the start. But switching horses in midstream from UDP to TCP hits all
>> sorts of ugly real world deployment issues.
> I would agree it should either all work in UDP or start in TCP.
> And Pauls' drafts are very relevant to this conversation.

Or possibly more practical would be to have a strategy where UDP is
the default but there is a fallback over HTTP.