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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 21 March 2014 11:32 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71C1A08B7 for <dns-privacy@ietfa.amsl.com>; Fri, 21 Mar 2014 04:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-47mv37FA2J for <dns-privacy@ietfa.amsl.com>; Fri, 21 Mar 2014 04:32:58 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BA1741A08AE for <dns-privacy@ietf.org>; Fri, 21 Mar 2014 04:32:57 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id pv20so1583620lab.10 for <dns-privacy@ietf.org>; Fri, 21 Mar 2014 04:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.112.94.229 with SMTP id df5mr5470327lbb.36.1395401567834; Fri, 21 Mar 2014 04:32:47 -0700 (PDT)
Received: by 10.112.234.229 with HTTP; Fri, 21 Mar 2014 04:32:47 -0700 (PDT)
In-Reply-To: <532BC100.4050704@gmail.com>
References: <CAMm+LwgXExHH6YxpvQLEsgZ+C4uUjvv0E=+g0XBmWVBrQnG_-w@mail.gmail.com> <CA+9kkMAVkUtLZ95g-Enk1EaSif4FOuuCy_utwcHYDN3Vjw3xjg@mail.gmail.com> <CAMm+Lwi_aLqyyC4ek_twcr_x_XC6J1AOFbEgJkHaAe=skfSmLw@mail.gmail.com> <532A9BDF.80401@nlnetlabs.nl> <CAMm+LwjysRvkKqH=HeuQtxf8Kh0VRBDzwW63G0Z58yb0ptQB2w@mail.gmail.com> <532BC100.4050704@gmail.com>
Date: Fri, 21 Mar 2014 07:32:47 -0400
Message-ID: <CAMm+LwhP9YNu+tOWCs7TTV-cguB4tvPf1B5e8V_KOSaDuJq_kw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/H6-olNTqm8Z2NoR08SpGRgjKySQ
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 11:33:00 -0000

On Fri, Mar 21, 2014 at 12:33 AM, Tim Wicinski <tjw.ietf@gmail.com> 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.

-- 
Website: http://hallambaker.com/