Dear Roy, Joe, and Eberhard,
If I understand section 4.3 correctly, DNSSEC validating stub resolvers
SHOULD NOT resolve these names. Is that the intention of Section 4.3?
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.
Section 4.4 has a typo. “attempt to look up NS records for the,”
should be “attempt to look up NS records for them,”.
—Andrew
On 10 Apr 2021, at 14:45, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of
the IETF.
Title : Top-level Domains for Private Internets
Authors : Roy Arends
Joe Abley
Eberhard W. Lisse
Filename : draft-ietf-dnsop-private-use-tld-01.txt
Pages : 14
Date : 2021-04-10
Abstract:
There are no defined private-use namespaces in the Domain Name
System
(DNS). For a domain name to be considered private-use, it needs to
be future-proof in that its top-level domain will never be
delegated
from the root zone. The lack of a private-use namespace has led to
locally configured namespaces with a top-level domain that is not
future proof.
The DNS needs an equivalent of the facilities provided by BCP 5
(RFC
1918) for private internets, i.e. a range of short, semantic-free
top-level domains that can be used in private internets without the
risk of being globally delegated from the root zone.
This document describes a particular set of code points which, by
virtue of the way they have been designated in the ISO 3166
standard,
are thought to be plausible choices for the implementation of
private
namespaces that are anchored in top-level domains.
The ISO 3166 standard is used for the definition of eligible
designations for country-code top-level Domains. This standard is
maintained by the ISO 3166 Maintenance Agency. The ISO 3166
standard
includes a set of user-assigned code elements that can be used by
those who need to add further names to their local applications.
Because of the rules set out by ISO in their standard, it is
extremely unlikely that these user-assigned code elements would
ever
conflict with delegations in the root zone under current practices.
In order to avoid the operational and security consequences of
collisions between private and global use of these code elements as
top-level domains, this document specifies that such top-level
domains should never be deployed in the global namespace, and
reserves them accordingly in the Special-Use Names Registry
[RFC6761].
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-private-use-tld-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-private-use-tld-01
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-private-use-tld-01
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
