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

Mateusz Jończyk <mat.jonczyk@o2.pl> Thu, 14 June 2018 19:12 UTC

Return-Path: <mat.jonczyk@o2.pl>
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 0E38C130EAF for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 bLuun_tV4h1R for <doh@ietfa.amsl.com>; Thu, 14 Jun 2018 12:12:28 -0700 (PDT)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 4F7CF130E74 for <doh@ietf.org>; Thu, 14 Jun 2018 12:12:27 -0700 (PDT)
Received: (wp-smtpd smtp.tlen.pl 32728 invoked from network); 14 Jun 2018 21:12:23 +0200
Received: from agkn52.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.141.52]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for <doh@ietf.org>; 14 Jun 2018 21:12:23 +0200
To: Sara Dickinson <sara@sinodun.com>, DoH WG <doh@ietf.org>
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>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
Openpgp: preference=signencrypt
Message-ID: <40ac87db-dfdb-5305-338d-ff3afb8e159d@o2.pl>
Date: Thu, 14 Jun 2018 21:12:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <74D48781-9F05-482C-ACB2-7AB027611489@sinodun.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="B9RhGjLrglHhKUfBLuXZ52wkYs5XQBuer"
X-WP-MailID: a27459fca9fb4423f541906f2ce5c6cd
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 0000000 [saOU]
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/Oea8a-PcdDC-0U4BbQU0BbRFqVc>
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 19:12:32 -0000

W dniu 14.06.2018 o 16:00, Sara Dickinson pisze:
> Applications are free to decide it but it is not without consequences, for example:
> 
> 1) Many enterprises rely on using internal views for DNS from servers provided by DHCP. If applications override this by _default_ then that model completely breaks internal name resolution _and_ leaks internal queries to the external resolver. Some might consider that a loss of security and privacy. 
> 
> 2) By ‘users’ above I think you mean ‘application developers’ not ‘actual end users’? While their may be good reasons for application developers to want to do this I would postulate that actual end users who understand enough about DNS to want to control it would prefer to have a single system setting to configure it to point at _their_ preferred resolver, rather than a (transport/DNSSEC/resolver) setting existing in every individual application. 
> 
> I’m not saying there is a right or wrong model here, just that there are more concerns than simply what the application prefers. 
> 
> Sara. 
> 
+1
There is a need for robust DHCP to discover DOH servers.

I hope that separate DOH settings in web browsers are just a stopgap measure
until operating systems will support DOH.

Greetings,
Mateusz