Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

"Hewitt, Rory" <rhewitt@akamai.com> Mon, 18 March 2019 16:44 UTC

Return-Path: <rhewitt@akamai.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D5131117 for <doh@ietfa.amsl.com>; Mon, 18 Mar 2019 09:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.852
X-Spam-Level:
X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 FwJhocUKUEw3 for <doh@ietfa.amsl.com>; Mon, 18 Mar 2019 09:44:46 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6315E131135 for <doh@ietf.org>; Mon, 18 Mar 2019 09:44:46 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x2IGb7Tm012986; Mon, 18 Mar 2019 16:44:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=o6JCiRpxCcEtrRdP9N+W460VoGZVbKS/6DqqNKgJUPI=; b=bE2glDdaFuaSnK8r1RIs4hOC2cIkjnClZUwFLAodegQjMF9Y/g1THMOrs/rObXU5bikC EPOEcGwAHAjRLxNVkivW/bm0CUMhibz2dOU89vh/0ZZfAVWu5vmlhPk7eAIbn/6uELjW dXU/3T6BncgxdZHnsVCQijpSLmfO3ZE4d6wAvZoTWK+mEPkj/epLLbWj9WdZ1urSAa1t FwxkmOvtbrt2T1Or5IuPpA/HB7y21xSp4XDYPZzOYklhIxBuMmWWCgNI32gjVuQK/iZD r+Lz9iGeeC/NcdpvBLH1gzvMDIC+yJWLYNJSI2iPZUX2OkK3QWEbdqvNs0rZMUyKk90S Bw==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2r8s9tst4u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Mar 2019 16:44:25 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2IGXeCV018998; Mon, 18 Mar 2019 12:44:23 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint1.akamai.com with ESMTP id 2r8vfv33sh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Mar 2019 12:44:23 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 11:44:15 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1473.003; Mon, 18 Mar 2019 11:44:15 -0500
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Paul Hoffman <paul.hoffman@icann.org>, DoH WG <doh@ietf.org>
Thread-Topic: [Doh] [Ext] Reviewing Resolver-Associated DOH
Thread-Index: AQHU3RjEfZ1VPcdKSEuf1fAXMLhziaYRl5QA
Date: Mon, 18 Mar 2019 16:44:14 +0000
Message-ID: <392246eb108b4421b63f0813f71d3b75@ustx2ex-dag1mb3.msg.corp.akamai.com>
References: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com> <5690c5b2-65ab-55d4-b3ec-d06d82ebbb26@riseup.net> <7F06A457-58C6-47A0-BDCA-D25FF0C6C062@icann.org> <b5c7f08d-debc-b426-f72d-b5100c476b4f@it.aoyama.ac.jp>
In-Reply-To: <b5c7f08d-debc-b426-f72d-b5100c476b4f@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.28.212.170]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-18_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903180122
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-18_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903180123
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/rtZMoEJWcZxGjobqI2p97fzanyw>
Subject: Re: [Doh] [Ext] Reviewing Resolver-Associated DOH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 16:44:50 -0000

I understand that we don't necessarily want a directory structure under /.well-known/ - therefore I would suggest one of the following:

/.well-known/dns-doh/
/.well-known/dns-doh-servers/

I just don't want to end up with a situation where a single-layer structure results in the /.well-known/ folder containing hundreds of poorly-named files. We're already seeing some people using this folder to store not only things like robots.txt, but also assorted Apple and Google files and their own internal 'constant' data.

Therefore, at a minimum, 'our' files should be named consistently - meaning that (IMHO) any DNS-related file should begine with "dns-". Not sure whether we're in a position to influence IANA to implement a naming standard...

Rory

-----Original Message-----
From: Martin J. Dürst <duerst@it.aoyama.ac.jp> 
Sent: Sunday, March 17, 2019 4:26 PM
To: Paul Hoffman <paul.hoffman@icann.org>; DoH WG <doh@ietf.org>
Subject: Re: [Doh] [Ext] Reviewing Resolver-Associated DOH

On 2019/03/17 01:04, Paul Hoffman wrote:
> 
> On Mar 16, 2019, at 8:51 AM, nusenu <nusenu-lists@riseup.net> wrote:

> On Mar 16, 2019, at 8:51 AM, nusenu <nusenu-lists@riseup.net> wrote:
>> Hewitt, Rory wrote:
>>> As with all /.well-known/ endpoints, the issue is both 
>>> standardization and publicization. AIUI, @mnot's original ideal 
>>> would be to have /.well-known/ be pretty 'generic'. Therefore I'm 
>>> not a fan of "/doh-servers-associated/" - I'd much rather see 
>>> "/dns/doh/", which would enable other (future) DNS-related 
>>> functionality to have a sub-folder within "/.well-known/dns/". If 
>>> that's not a possibility, what about "/.well-known/dns-doh/"?
>>
>> +1
>>
>> I find these suggested .well-known URLs clearer than "doh-servers-associated".
> 
> I'm generally against this idea for two reasons:
> 
> - No one will see this URL other than software developers and operators watching their logs. They will not be visible to users.
> 
> - Layered spaces under a .well-known/ are possible but I don't think they are well-understood.

I very much agree. It could make things more complicated for IANA, and it could make things more complicated for server administrators. Even if the additional level of complexity is minimal in many cases, it may not be in others.

I'm not against including the three-letter acronym 'dns' in the string somehow; that may help administrators who look at .well-known a while after somebody got that folder set up.

Regards,   Martin.