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

Paul Hoffman <paul.hoffman@icann.org> Sun, 24 March 2019 10:46 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 42019129515 for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 03:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt2S3h4WiuFR for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 03:46:34 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50C81286E7 for <dnsop@ietf.org>; Sun, 24 Mar 2019 03:46:31 -0700 (PDT)
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 Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 24 Mar 2019 03:46:29 -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; Sun, 24 Mar 2019 03:46:29 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: bert hubert <bert.hubert@powerdns.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] New draft for consideration:
Thread-Index: AQHU4irucsOrl7FTzEuPNRVnouziKqYbDq4A
Date: Sun, 24 Mar 2019 10:46:28 +0000
Message-ID: <6893EFA4-F413-4C11-828A-13E942AA345C@icann.org>
References: <E2267015-0A5F-4D6E-85F0-3FA93348CA79@icann.org> <20190324101805.GA22597@server.ds9a.nl>
In-Reply-To: <20190324101805.GA22597@server.ds9a.nl>
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.47.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <63DDB293340B514CBFFDF560C1B2F361@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kRW3laTsGF6LGqXSpEGV4pNvfOQ>
Subject: Re: [DNSOP] [Ext] Re: New draft for consideration:
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 24 Mar 2019 10:46:35 -0000

On Mar 24, 2019, at 11:18 AM, bert hubert <bert.hubert@powerdns.com> 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.

Thanks!

--Paul Hoffman