IETF Logo Mail Archive

[DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

Paul Hoffman <paul.hoffman@icann.org> Fri, 16 April 2021 15:18 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 442F53A296F for <dnsop@ietfa.amsl.com>; Fri, 16 Apr 2021 08:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 ur1DoGh4L-77 for <dnsop@ietfa.amsl.com>; Fri, 16 Apr 2021 08:18:27 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 BF8E33A296B for <dnsop@ietf.org>; Fri, 16 Apr 2021 08:18:27 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.43/8.16.0.43) with ESMTPS id 13GFINVE030414 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Apr 2021 15:18:24 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.5; Fri, 16 Apr 2021 08:18:23 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0858.010; Fri, 16 Apr 2021 08:18:23 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Andrew McConachie <andrew@depht.com>
CC: DNSOP Working Group <dnsop@ietf.org>
Thread-Topic: Questions on draft-ietf-dnsop-private-use-tld-01.txt
Thread-Index: AQHXMtO96O/pwkwD/EWeq8N34C2VSQ==
Date: Fri, 16 Apr 2021 15:18:22 +0000
Message-ID: <5F3F8198-23EA-4BA9-A07E-EF7AB035CE72@icann.org>
References: <161805873252.19178.11471347094062424385@ietfa.amsl.com> <88395F35-AF22-489C-B9D6-2FFE4EB1A767@depht.com>
In-Reply-To: <88395F35-AF22-489C-B9D6-2FFE4EB1A767@depht.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_C9796421-5047-4AF9-BF59-AABC8AA5061D"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-16_07:2021-04-16, 2021-04-16 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CJUna0UPnnKNc6tAZ2dC0GFcs2E>
Subject: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt
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: Fri, 16 Apr 2021 15:18:32 -0000

On Apr 16, 2021, at 5:31 AM, Andrew McConachie <andrew@depht.com> wrote:

> If I understand section 4.3 correctly, DNSSEC validating stub resolvers SHOULD NOT resolve these names. Is that the intention of Section 4.3?

No, definitely not. The text says:
   3.  Name resolution APIs and libraries SHOULD NOT recognise these
       names as special and SHOULD NOT treat them differently.  Name
       resolution APIs SHOULD send queries for these names to their
       configured caching DNS server(s).
Not recognizing them as special means to treat them like any other name. There is no mention of DNSSEC.

> Why reserve so many names for a singular purpose? If human semantics are irrelevant then why not just pick a name at random and reserve that one? There may come a time in the future where one of these names might be useful for something else.

The question of "why" is a good one. There are two extremes:

- All these labels are equivalent, so the WG should just allow one to be used.

- These labels have different semantic properties to different people, so let them choose freely among the set.

This hasn't been well-discussed in the WG. My personal preference is the latter (which is what is in the draft) because names and abbreviations matter, whether or not we techies like that. There is no technical downside to the list being large but bounded, I think. 

--Paul Hoffman

v2.23.0 | Report a Bug | By Email