Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver

Paul Hoffman <paul.hoffman@icann.org> Fri, 24 August 2018 14:25 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6ED1286E3 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 07:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CCB0oINkuYSQ for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 07:25:33 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8823D12008A for <dnsop@ietf.org>; Fri, 24 Aug 2018 07:25:33 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 24 Aug 2018 07:25:31 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Fri, 24 Aug 2018 07:25:31 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat+ietf@nic.cz>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver
Thread-Index: AQHUOz2eQiAKvFMVE0eX0eBhSBlxiKTPX9iAgAALowA=
Date: Fri, 24 Aug 2018 14:25:30 +0000
Message-ID: <61FF26F6-F2E2-48C8-A4B6-94FC6652D55E@icann.org>
References: <3D4A9165-6EE8-4997-A9F7-DB19632C25F3@icann.org> <5220d889-e587-d6dc-db45-0d76370eabae@nic.cz>
In-Reply-To: <5220d889-e587-d6dc-db45-0d76370eabae@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <10D6EC4F19C5A34ABEF2FA03EE42E665@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FbJWeYGYOpfXN-jU5x9mgiWQecg>
Subject: Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Aug 2018 14:25:35 -0000

On Aug 24, 2018, at 6:43 AM, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> On 08/24/2018 02:01 AM, Paul Hoffman wrote:
>> Thoughts?
> 
> Well, if the OS resolver is validating, it will SERVFAIL with such a
> query.  

The protocol requires special handling of those specific queries, so a resolver that understands the protocol will give the desired answer. A resolver that doesn't understand the answer will give NXDOMAIN even if it is validating because that RRtype is not in the root zone.

> Furthermore, if it uses aggressive caching, it may even give a
> negative reply without asking upstream that would answer positively. 

...which is fine for resolvers that do not know the protocol.

> That is, unless the RFC instructs forwarding resolvers to do otherwise,
> but that would seem a nasty special case for little benefit.

Forwarding resolvers do not need special casing, I believe. If the forwarding resolver understands the protocol, it will reply. If it doesn't understand the protocol, it will forward and give back whatever the upstream resolver tells it. 

> I assume the non-validation is a conscious tradeoff, as such resolvers
> seem not a common OS default, and they're more likely to support DoT or
> DoH anyway, hopefully reducing the need for browsers to roll their own.

I admit I had not considered validating stub resolvers. Now that you bring it up, a validating stub resolver will get an answer that cannot be validated, and thus will mark it Bogus. This feels like a limitation, but one that can't really be worked around unless we use a RFC 6761 TLD that is guaranteed to be unsigned.

> I'm not sure I understand the motivation for the stated use case, but
> apparently others perceive it as useful...

Restating the motivation: a browser that wants to use DoH might also want to let the user say "I trust the DoH server that my configured resolver is associated with". That eliminates the need to have DHCP know which DoH servers are associated with the Do53 servers that it is announcing, and it also eliminates the need for the OS to know about those DHCP updates.

Hopefully this helps. But thank you for bringing up the validating stub issue.

--Paul Hoffman