Subject: [DNSOP] I-D Action: draft-ietf-dnsop-private-use-tld-00.txt

From: [email-masked]
Date: Thu, 08 Oct 2020 02:54:34 -0700

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
	Filename        : draft-ietf-dnsop-private-use-tld-00.txt
	Pages           : 10
	Date            : 2020-10-08

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.

   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.
   This document explicitly reserves these code elements to be safely
   used as top-level domains for private DNS resolution.

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-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-private-use-tld-00

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/

---

From: "Andrew McConachie" <[email-masked]>
Date: Fri, 09 Oct 2020 11:38:04 +0200

> ftp://ftp.ietf.org/internet-drafts/
Hi Roy and Joe,

It’s not clear to me whether the document is advising to only use this 
facility when a sub-domain of a public domain name is unavailable, or to 
optionally use this facility based on the user’s preference. What I 
would like the document to say is that only when a sub-domain of a 
public domain is unavailable should this facility be considered. The 
reader should get the impression that they should try really really hard 
to not use the ISO-3166 reserved string if they can.

This is marked as a BCP and so I would expect to see this advice 
prominent in the document. Since, IMO at least, that is the best current 
practice. Only when a user cannot use a sub-domain of a domain they 
control should they even consider using the ISO-3166 reserved string. 
Ideally there could be a new section discussing this advice between the 
current sections 1 and 2. That way the reader will encounter the best 
practice before encountering the work around.

Thanks,
Andrew

---

From: Roy Arends <[email-masked]>
Date: Fri, 9 Oct 2020 10:58:35 +0100

> On 9 Oct 2020, at 10:38, Andrew McConachie <[email-masked]> wrote:
> Hi Roy and Joe,
> 
> It’s not clear to me whether the document is advising to only use this facility when a sub-domain of a public domain name is unavailable, or to optionally use this facility based on the user’s preference. What I would like the document to say is that only when a sub-domain of a public domain is unavailable should this facility be considered. The reader should get the impression that they should try really really hard to not use the ISO-3166 reserved string if they can.
> 
> This is marked as a BCP and so I would expect to see this advice prominent in the document. Since, IMO at least, that is the best current practice. Only when a user cannot use a sub-domain of a domain they control should they even consider using the ISO-3166 reserved string. Ideally there could be a new section discussing this advice between the current sections 1 and 2. That way the reader will encounter the best practice before encountering the work around.

Thanks for your comment Andrew,

The next version will contain more text directed to this.

IMHO, the mere availability of a subdomain (of an existing domain) should not automatically preclude the use of a private top-level domain. That is, I disagree with the notion that “they should try really really hard to not use the ISO-3166 reserved string”.

Note that a domain may not always be tied to the same legal entity. When software or devices are shipped with a default configuration that is meant to work only locally (there are a few scenarios that include home use or corporate use), using a public domain is problematic. Queries will leak to the authoritative servers of that public domain, long after the public domain has changed hands.

It is also not desirable from a legal and even operational standpoint if software that is shipped with a default public domain will be “phoning home” all the time.

There are likely to be many different use cases, some where a public domain is useful, some where a private-use domain is useful. 

Warm regards,

Roy

---

From: "Andrew McConachie" <[email-masked]>
Date: Wed, 14 Oct 2020 11:50:23 +0200

On 9 Oct 2020, at 11:58, Roy Arends wrote:

>> It’s not clear to me whether the document is advising to only use 
>> this facility when a sub-domain of a public domain name is 
>> unavailable, or to optionally use this facility based on the user’s 
>> preference. What I would like the document to say is that only when a 
>> sub-domain of a public domain is unavailable should this facility be 
>> considered. The reader should get the impression that they should try 
>> really really hard to not use the ISO-3166 reserved string if they 
>> can.
>>
>> prominent in the document. Since, IMO at least, that is the best 
>> current practice. Only when a user cannot use a sub-domain of a 
>> domain they control should they even consider using the ISO-3166 
>> reserved string. Ideally there could be a new section discussing this 
>> advice between the current sections 1 and 2. That way the reader will 
>> encounter the best practice before encountering the work around.
>
> IMHO, the mere availability of a subdomain (of an existing domain) 
> should not automatically preclude the use of a private top-level 
> domain. That is, I disagree with the notion that “they should try 
> really really hard to not use the ISO-3166 reserved string”.
>
> Note that a domain may not always be tied to the same legal entity. 
> When software or devices are shipped with a default configuration that 
> is meant to work only locally (there are a few scenarios that include 
> home use or corporate use), using a public domain is problematic. 
> Queries will leak to the authoritative servers of that public domain, 
> long after the public domain has changed hands.
>
> It is also not desirable from a legal and even operational standpoint 
> if software that is shipped with a default public domain will be 
> “phoning home” all the time.
>
> There are likely to be many different use cases, some where a public 
> domain is useful, some where a private-use domain is useful.

Hi Roy,

Thanks for the response. I think we’re basically in agreement here.

If the mere availability of a sub-domain (of an existing domain) 
precluded ever using this ISO-3166 reserved string then there would 
never be a valid use case for the ISO-3166 string. If only because one 
can always register a new domain and delegate a sub-domain. We can 
quibble over what “try really really hard” means, but it would not 
improve the document to enumerate every possible use case and proscribe 
which route the user should take for each one.

I look forward to your next version with more text on this topic.

Thanks,
Andrew