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

Paul Hoffman <> Fri, 24 August 2018 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF06612F295 for <>; Fri, 24 Aug 2018 07:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C6ZyAJfGR05p for <>; Fri, 24 Aug 2018 07:56:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4681128CE4 for <>; Fri, 24 Aug 2018 07:56:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 24 Aug 2018 07:56:13 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Fri, 24 Aug 2018 07:56:13 -0700
From: Paul Hoffman <>
To: Philip Homburg <>
CC: "" <>
Thread-Topic: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
Thread-Index: AQHUO7kiuY2F7K9+5U+uqgyxe1x2WaTPcxeA
Date: Fri, 24 Aug 2018 14:56:12 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Re: New draft for helping browsers use the DoH server associated with a resolver
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Aug 2018 14:56:16 -0000

On Aug 24, 2018, at 7:45 AM, Philip Homburg <> wrote:
>>> 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.
> It seems to go wrong when you have one validating resolver that forwards to a
> resolver that supports this mechanism.

Agree. This might mean that using an unsigned 6761 special use domain name would be better.

> It don't really see the point of what you propose. For resolvers obtained by
> DHCP it makes more sense to include the URL in the DHCP reply than to have
> yet another DNSSEC-violating discovery hack.

Two reasons here (although they might not be convincing):

- This proposal works for browsers even if the OS doesn't understand a new DHCP extension for DoH server URI templates

- It relives the DHCP server admin from needing to know which DoH servers are associated with a particular Do53 server.

As I hope I made clear in the proposal, it will work even if there is a new DHCP extension for the OS. It just doesn't rely on it.

> For manually configured resolvers, it is likely more convenient for the user
> to just enter the URL and let the system figure out the addresses of the
> resolvers.

Again, it is not clear how that information would get to the browsers. They have a hard enough time getting good answers to "what is the address being used for the resolver".

> Figuring out what SNI to use using insecure DNS sort of negates any advantage
> TLS authentication offers.

I don't understand this at all. The SNI is the host in the URI template.

--Paul Hoffman