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

"John Todd" <> Fri, 24 August 2018 01:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDD87130FA3 for <>; Thu, 23 Aug 2018 18:29:37 -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 15T0UxxtoSM0 for <>; Thu, 23 Aug 2018 18:29:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F3A4130DFE for <>; Thu, 23 Aug 2018 18:29:35 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15CEE2C21D5; Thu, 23 Aug 2018 18:33:47 -0700 (PDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10032) with ESMTP id nP5n3xz0_Eo2; Thu, 23 Aug 2018 18:33:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F4DC2C21D6; Thu, 23 Aug 2018 18:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id H1Jibs4cHkaP; Thu, 23 Aug 2018 18:33:46 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id AD7A12C21D5; Thu, 23 Aug 2018 18:33:45 -0700 (PDT)
From: "John Todd" <>
To: "Paul Hoffman" <>
Cc: dnsop <>
Date: Thu, 23 Aug 2018 18:29:31 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] 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 01:29:48 -0000

Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a 
previously-granted resolver via DHCP was, then a lookup and 
result of:  86400 IN SRV 10 60 443

  …would provide the client with a DOH resolver at 
“” after a subsequent and hopefully final non-DOH 
lookup on the name(s). Or multiple DOH resolvers could be returned, if 
one wished to use SRV expansion to its full extent.

  I know there are some leakage problems here in certain cases to 
upstream resolvers, and there is a serious fundamental problem with the 
first-query (bootstrap) trust chain in a practical sense, but the same 
issue exists with a new RR type and I suspect will be far longer to 
implement a new RR type than to use SRV which already exists. I see the 
risks as close to identical.

  “DOH” of course isn’t an official service name, but RFC2782 
allows for service names that are local, so maybe there is a task to get 
“doh” turned into an official service name but in the meantime it 
can work without official nomenclature. It’s entirely possible 
“doh” is already on track or listed as a service name and I’ve 
missed it, despite the fact that it is really just HTTPS, even though 
we’re overloading the service type, as seems to be the case for 
[everything]-over-HTTPS.  That seems thin as an objection.

  I’m probably overlooking an obvious reason that this isn’t a use 
case for SRV, but it’s been a long day in a different timezone than 
I’m used to. Slings and arrows welcome.


On 23 Aug 2018, at 17:01, Paul Hoffman wrote:

> Greetings again. Some of the people in the recent thread about 
> "dynamic discovery of secure resolvers" have expressed an interest in 
> something that was mentioned at the DRIU BoF in Montréal: they want 
> their browser to use a DoH server that is related to the DNS resolver 
> that their OS is already using. I don't think DHCP can help with that 
> problem (I could be wrong), but I do think that resolver operators 
> should be able to tell browsers the DoH resolvers that they would want 
> their customers to be using.
> Please see the draft below. If folks like it, I can continue to work 
> on it. Or, if you like the use case but have a better technical 
> solution, that would be great too. I wanted to bring it to this list 
> before taking it to the DOH WG because it really is an operational 
> issue, not all that related to the DoH protocol.
> Thoughts?
> --Paul Hoffman
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> Title : Associating a DoH Server with a Resolver
> Author : Paul Hoffman
> Filename : draft-hoffman-resolver-associated-doh-00.txt
> Pages : 8
> Date : 2018-08-23
> Abstract:
> Some clients will want to know if there are one or more DoH servers
> associated with the DNS recursive resolver that the client is already
> using. This document describes a protocol for a resolver to tell a
> client what its associated DoH servers are.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list