IETF Logo Mail Archive

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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 27 November 2019 14:44 UTC

Return-Path: <bortzmeyer@nic.fr>
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 BE76C1208F0 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 06:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 iSBQCOMRD676 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 06:44:57 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 63A611208E4 for <dns-privacy@ietf.org>; Wed, 27 Nov 2019 06:44:57 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id EE26E280601; Wed, 27 Nov 2019 15:44:55 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id E7A9228071C; Wed, 27 Nov 2019 15:44:55 +0100 (CET)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id DFF70280601; Wed, 27 Nov 2019 15:44:55 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D848A6A9F3A0; Wed, 27 Nov 2019 15:44:55 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id CE4474028D; Wed, 27 Nov 2019 15:44:55 +0100 (CET)
Date: Wed, 27 Nov 2019 15:44:55 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Neil Cook <neil.cook@noware.co.uk>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Phillip Hallam-Baker <phill@hallambaker.com>, dns-privacy@ietf.org
Message-ID: <20191127144455.GB18601@nic.fr>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <4E2DE849-CC35-4675-9A41-CD134D65371A@noware.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E2DE849-CC35-4675-9A41-CD134D65371A@noware.co.uk>
X-Operating-System: Debian GNU/Linux 10.2
X-Kernel: Linux 4.19.0-6-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Bogosity: No, tests=bogofilter, spamicity=0.001042, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/v4tDszWuWuhvjrc0AT6oMG21Cac>
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: Wed, 27 Nov 2019 14:44:59 -0000

On Wed, Nov 27, 2019 at 10:04:57AM +0000,
 Neil Cook <neil.cook@noware.co.uk> wrote 
 a message of 45 lines which said:

> I don’t see why they’re broken by design;

You explained it well:

> they add no security properties

> on top of the (insecure) DHCP mechanism used to contact the resolver
> in the first place

And the problem is not the (in)security of DHCP. The problem is that
if you don't trust the access network to provide you with a secure
resolver, why would you trust it to indicate one? If the default
resolver (DNS over UDP, obtained through DHCP) lies or records
personal data, why would the resolver found by "resolver discovery" be
better?

> how clients use that information is up to them. They may or may not
> decide to trust that resolver,

OK, if it is clearly specified, I understand. But it is far from
clear, for instance in draft-reddy-dprive-bootstrap-dns-server.

v2.23.0 | Report a Bug | By Email