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

Neil Cook <neil.cook@noware.co.uk> Wed, 27 November 2019 10:05 UTC

Return-Path: <neil.cook@noware.co.uk>
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 1A7BB1200C3 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 02:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-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 fQhjS8M08Dgm for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 02:04:59 -0800 (PST)
Received: from mail.noware.co.uk (unknown [IPv6:2604:a880:0:1010::add:2001]) by ietfa.amsl.com (Postfix) with ESMTP id AA0BB1200B2 for <dns-privacy@ietf.org>; Wed, 27 Nov 2019 02:04:59 -0800 (PST)
Received: from [192.168.1.170] (unknown [81.151.217.120]) by mail.noware.co.uk (Postfix) with ESMTPSA id BC4A81D919A; Wed, 27 Nov 2019 09:54:28 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Neil Cook <neil.cook@noware.co.uk>
In-Reply-To: <20191126180441.GA4452@sources.org>
Date: Wed, 27 Nov 2019 10:04:57 +0000
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E2DE849-CC35-4675-9A41-CD134D65371A@noware.co.uk>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3601.0.10)
X-VADE-SPAMSTATE: clean
X-VADE-SPAMSCORE: -100
X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudeihedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupffgkffnvefqqffmnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpefpvghilhcuvehoohhkuceonhgvihhlrdgtohhokhesnhhofigrrhgvrdgtohdruhhkqeenucfkphepkedurdduhedurddvudejrdduvddtnecurfgrrhgrmhepihhnvghtpeekuddrudehuddrvddujedruddvtddphhgvlhhopegludelvddrudeikedruddrudejtdgnpdhmrghilhhfrhhomheppfgvihhlucevohhokhcuoehnvghilhdrtghoohhksehnohifrghrvgdrtghordhukheqpdhrtghpthhtohepsghorhhtiihmvgihvghrsehnihgtrdhfrhdprhgtphhtthhopehphhhilhhlsehhrghllhgrmhgsrghkvghrrdgtohhmpdhrtghpthhtohepughnshdqphhrihhvrggthiesihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ZY79ySfGW21qNDxLhKnDDxIEvhA>
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 10:05:01 -0000

> On 26 Nov 2019, at 18:04, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
>> 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.

Resolver discovery schemes allow a client to ask the local resolver to provide information about the resolver, such as DoH info, as well as potentially other information about the resolver. I don’t see why they’re broken by design; yes they add no security properties on top of the (insecure) DHCP mechanism used to contact the resolver in the first place, but how clients use that information is up to them. They may or may not decide to trust that resolver, they may have a preconfigured list of trusted DoH servers, they may use it only to bootstrap connections to other servers, as suggested below. You may for example prefer your _doh.MYDOMAIN.example/SRV request to be sent over an encrypted connection.

Also without a discovery protocol, the only way to use an encrypted DNS connection would be to manually enter it , or use a pre-configured centralised DNS service using the Mozilla model. I’d much rather see all those existing non-encrypted connections moved to encrypted connections (using DoT or DoH) by default - it doesn’t preclude anything else you’ve suggested. It also doesn’t means that users who are depending on services provided by their local resolver (such as malware filtering, parental controls), would continue to be able to make use of 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...)


Neil