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

Paul Hoffman <> Fri, 24 August 2018 02:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 601F5130E59 for <>; Thu, 23 Aug 2018 19:04:20 -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 zaw01YZIRyv8 for <>; Thu, 23 Aug 2018 19:04:18 -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 95FCB130E27 for <>; Thu, 23 Aug 2018 19:04:18 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 23 Aug 2018 19:04:16 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Thu, 23 Aug 2018 19:04:16 -0700
From: Paul Hoffman <>
To: John Todd <>
CC: dnsop <>
Thread-Topic: [Ext] Re: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver
Thread-Index: AQHUOz2eQiAKvFMVE0eX0eBhSBlxiKTOkq2AgAAJtIA=
Date: Fri, 24 Aug 2018 02:04:16 +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="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
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 02:04:21 -0000

On Aug 23, 2018, at 6:29 PM, John Todd <> wrote:
> 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 don't think this works for two orthogonal reasons:

- The browser doesn't necessarily know that address of the recursive resolver, just how to send queries to the recursive resolver through the OS's stub resolver

- Recursive resolvers don't all have control of their reverse address mappings in

Even if both of those are fixed, it will yield less secure results because is not signed in DNSSEC, so attackers in the middle will always be able to change the responses (as compared to only being able to some of the time with the RAD RRtype I proposed).

> 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

Fully agree

> and I suspect will be far longer to implement a new RR type than to use SRV which already exists.

This doesn't seem to as daunting to me. On the client side, if a browser has a DoH client, it already has a full DNS stack, so adding in the requirement to be able to ask for RRtype TBD seems trivial. On the resolver side, it needs to have generic capture code to look for ./IN/RAD, and resolvers already have much more complicated code in them.

> 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.

Hopefully the above is neither slings nor arrows!

--Paul Hoffman