Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Stephane Bortzmeyer <bortzmeyer@nic.fr> Tue, 26 November 2019 18:08 UTC

Return-Path: <stephane@sources.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0C120A1C for <dns-privacy@ietfa.amsl.com>; Tue, 26 Nov 2019 10:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 YAfaCunQXB_g for <dns-privacy@ietfa.amsl.com>; Tue, 26 Nov 2019 10:08:10 -0800 (PST)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (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 0711C120A02 for <dns-privacy@ietf.org>; Tue, 26 Nov 2019 10:08:09 -0800 (PST)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id A7EFCA02A0; Tue, 26 Nov 2019 19:08:06 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000) id 2B069C9571; Tue, 26 Nov 2019 19:04:41 +0100 (CET)
Date: Tue, 26 Nov 2019 19:04:41 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: dns-privacy@ietf.org
Message-ID: <20191126180441.GA4452@sources.org>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 10.1
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/DI_us6K5DRpcueXWPhwAKZyV9ec>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Nov 2019 18:08:11 -0000

On Tue, Nov 26, 2019 at 12:35:13PM -0500,
 Phillip Hallam-Baker <phill@hallambaker.com> wrote 
 a message of 166 lines which said:

> 2) Admin/User Configured DNS
>     The client obtains the information to connect to a resolver through an
> Administrator or User configuration action. This may be inserting an IP
> address (8.8.8.8/1.1.1.1/etc) or some form of DNS label.
> 
> 3) Application/Platform Provider Configuration.
>     The application or OS platform can simply ignore user preferences and
> choose a DNS provider of its own liking.

Note that, for free software, there is no real difference between 2)
and 3). Someone can always change the source and recompile. (And there
is of course no real privacy without free software.)

> But please, assure me that we are not the brink of users being faced
> with pop ups asking them 'would you like to choose me as your DNS
> provider'.

Why not? But, anyway, the IETF does not do UI so it's not really our
job.

> Of these three models, I have always considered (1) to be a security
> hole.

I fully agree. *All* "automatic discovery of the DoH resolver" schemes
are broken by design and I really wonder why people keep suggesting
them.

> So what I see is a requirement for DNS resolver configuration. We
> already have rfc6763 to tell us how to get from a DNS label to an
> Internet service.  Albeit one that presupposes the existence of a
> resolution mechanism. I don't see it being problematic to use the
> local DNS to do this resolution provided that 1) we have the means
> to authenticate the connection and 2) we only use this mechanism
> once, to perform initial configuration.

I agree too. A simple _doh.MYDOMAIN.example/SRV request would
suffice. (Even better, HTTP should support SRV, but I digress...)