Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

Sara Dickinson <sara@sinodun.com> Thu, 14 June 2018 14:38 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A825712777C for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 07:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OLn6yZS97j_V for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 07:38:40 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859B1130E46 for <doh@ietf.org>; Thu, 14 Jun 2018 07:38:39 -0700 (PDT)
Received: from [2001:b98:204:102:fffa::409] (port=50899) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1fTTOU-0001nN-3A; Thu, 14 Jun 2018 15:38:38 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <alpine.DEB.2.20.1806141609050.29598@tvnag.unkk.fr>
Date: Thu, 14 Jun 2018 15:38:32 +0100
Cc: DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D920175F-4D1D-4D68-BCAA-F7FD23072D93@sinodun.com>
References: <1E183D79-5716-47E5-8604-A4F5DC7588C2@icann.org> <045241e6-6d9f-162c-6ae3-0b10d59d21de@bellis.me.uk> <6BB0D47F-2BA3-4D9A-A125-1D1E180B06E0@icann.org> <53c320bc-6ea0-21f4-c7a1-1da34bbdb38d@nic.cz> <CAHbrMsBoKE-pfz97ZDb9ReLKMedk2KJ7xLCw_MPmxVtqF7PcuA@mail.gmail.com> <20180613192030.GA2792@jurassic> <CAHbrMsACdaz13v=2jbpZq1RU-_CP36Cgz13iFFWVj8qrjQ0b=g@mail.gmail.com> <20180613205637.GA23215@jurassic> <CAOdDvNr0ob_zhMw1BT_h8n77ecx5vht8WJ7OiwwDPrj0Wxf8SA@mail.gmail.com> <20180614042217.GA25915@jurassic> <20180614044113.GA27115@jurassic> <alpine.DEB.2.20.1806140728270.30130@tvnag.unkk.fr> <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com> <alpine.DEB.2.20.1806141609050.29598@tvnag.unkk.fr>
To: Daniel Stenberg <daniel@haxx.se>
X-Mailer: Apple Mail (2.3445.8.2)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/WRca6-wWq_3TuiGTJL2xFrSDRto>
Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jun 2018 14:38:43 -0000


> On 14 Jun 2018, at 15:09, Daniel Stenberg <daniel@haxx.se> wrote:
> 
> On Thu, 14 Jun 2018, Sara Dickinson wrote:
> 
>> I’m not saying there is a right or wrong model here, just that there are more concerns than simply what the application prefers.
> 
> Sure. And I'm saying they already existed since long before and are independent of DOH.

I don't disagree (note I did not mention DoH at all in my response). I was replying to the generic question “Why shouldn’t application be able to decide to use their own preferred resolvers”.

But it is also true to say that prior to DoH applications that made that choice were the _exception_ and not the norm, whereas it seems highly likely that many applications (and most browsers) will soon all choose to perform DoH themselves, making this new model a reality that has to be addressed. That fundamentally shifts the role of DNS and DHCP within the end user device infrastructure and the raises questions about the concept of implicit choice of DNS resolver (e.g. the network resolver vs application resolver).

The observation here is that this shift is being directly driven today by applications wanting to use DoH to their preferred resolver for a variety of reasons, not by (for example) operating systems, enterprises, ISPs, end users or the DNS community. 

Sara.