Re: [DNSOP] [Ext] Re: New draft for consideration:

Paul Hoffman <> Sun, 24 March 2019 10:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42019129515 for <>; Sun, 24 Mar 2019 03:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zt2S3h4WiuFR for <>; Sun, 24 Mar 2019 03:46:34 -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 A50C81286E7 for <>; Sun, 24 Mar 2019 03:46:31 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 24 Mar 2019 03:46:29 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Sun, 24 Mar 2019 03:46:29 -0700
From: Paul Hoffman <>
To: bert hubert <>
CC: dnsop <>
Thread-Topic: [Ext] Re: [DNSOP] New draft for consideration:
Thread-Index: AQHU4irucsOrl7FTzEuPNRVnouziKqYbDq4A
Date: Sun, 24 Mar 2019 10:46:28 +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 consideration:
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Mar 2019 10:46:35 -0000

On Mar 24, 2019, at 11:18 AM, bert hubert <> wrote:
> It may be good to add a note that "DoH is the protocol as defined in
> [RFC8484]. The operation of this protocol by browser vendors and cloud
> providers is frequently also called 'DoH'. DoH-the-protocol is
> therefore frequently conflated with DoH being used to perform
> DNS lookups in a different fashion than configured by the network settings
> (see DaT and DaO)."

A much better outcome would be that people who are saying DoH when they mean DaT or DaO would use the new terms. That is, this is a forward-looking document because we're making up new terms.

> Secondly, I understand the technical need for the wording of the definition
> of DaO.  But I had to read this all a few times before I understood that
> 'DaO' includes what I've referred to as DoC (DNS over Cloud). I think
> definitions should be easy to understand because otherwise they don't
> function.

I fully agree; proposed changes to this wording are quite welcome. It's a new term, after all.

> I'm also not too hot for conflating "user consciously changes
> /etc/resolv.conf or equivalent" with "application makes the choice for the
> user". 

The split here is more "someone changes from traditional without the user knowing, when the user cares". If you have a better way to express that, that would be great.

> Perhaps we should talk about 'Per-application stubs'? Because this is the
> nub. 

Maybe, but I'm hesitant to make the break that way because some applications' stubs use the traditional resolver, others don't. I would be hesitant to conflate those two.

> I'm willing to write text once we have discussed this a bit.


--Paul Hoffman