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

From: [email-masked]
Date: Sat, 10 Apr 2021 05:45:32 -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
                          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/

---

From: "Andrew McConachie" <[email-masked]>
Date: Fri, 16 Apr 2021 14:31:01 +0200

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, [email-masked] wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Apr 2021 15:18:22 +0000

On Apr 16, 2021, at 5:31 AM, Andrew McConachie <[email-masked]> 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

---

From: "Andrew McConachie" <[email-masked]>
Date: Mon, 19 Apr 2021 16:17:52 +0200

On 16 Apr 2021, at 17:18, Paul Hoffman 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?
>

I realize now my question was unclear. My understanding is that a DNSSEC 
validating stub SHOULD attempt to validate these names, which will fail. 
Therefore a DNSSEC validating stub cannot use these names.

Thanks,
Andrew

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Apr 2021 16:33:30 +0000

On Apr 19, 2021, at 7:17 AM, Andrew McConachie <[email-masked]> wrote:
> I realize now my question was unclear. My understanding is that a DNSSEC validating stub SHOULD attempt to validate these names, which will fail. Therefore a DNSSEC validating stub cannot use these names.

That's correct, as it would be for any private-use TLD. In fact, it's not just about validating stubs: an organization wanting to use a private-use TLD cannot have validating stub resolvers or validating recursive resolvers anywhere in the organization.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2021 12:53:03 -0400

It appears that Paul Hoffman  <[email-masked]> said:
>That's correct, as it would be for any private-use TLD. In fact, it's not just about validating stubs: an organization wanting to use a
>private-use TLD cannot have validating stub resolvers or validating recursive resolvers anywhere in the organization.

Sure they can, but they need to know which are the private-use TLDs.

Doing this in recursive resolvers is fairly straightforward,
particularly since the resolvers need to be configured to know where
to look up the private-use TLDs anyway. In validating stubs it seems
to be more of research problem, particularly how to bootstrap them.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Mon, 19 Apr 2021 11:35:00 -0700

On Mon, Apr 19, 2021 at 9:34 AM Paul Hoffman <[email-masked]> wrote:

> resolvers SHOULD NOT resolve these names. Is that the intention of Section
> 4.3?
> >>
> That's correct, as it would be for any private-use TLD. In fact, it's not
> just about validating stubs: an organization wanting to use a private-use
> TLD cannot have validating stub resolvers or validating recursive resolvers
> anywhere in the organization.
>

I think there is value in highlighting the root problem, and its
implications.
Private-use TLDs will fail DNSSEC validation which uses the IANA DNSSEC
Root Trust Anchor.
Organizations using names beneath such private-use TLDs while operating
validating recursive resolvers or validating stub resolvers need to also
manage trust anchors for those domains on those hosts. Such a trust anchor
could be used to either sign the domain, or prove the unsigned nature of
the domain.

(It may be an implementation-specific issue and/or specification issue, as
to how multiple trust anchors are handled. I.e. I'm not 100% sure off hand
if the current specifications are compatible with my statements. If they
aren't, IMHO they should be either revised or made more clear so as to
support use cases like this.)

Brian Dickson

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2021 15:27:46 -0400

>could be used to either sign the domain, or prove the unsigned nature of

If your recursive resolver is going to handle a private TLD, you need
to configure it so it knows where to find the contents of that TLD.
When you do that, the DNSSEC opt-out generally comes along for free.

Unbound and BIND have simple commands to do that, haven't looked at
other resolvers but those two probably cover half the market.

R's,
John

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 27 Apr 2021 22:34:44 -0400

I am not comfortable with grabbing all the permanently unassigned 2-letter
country codes for DNS private use.

Note: I was the primary author of RFC 2606 and have been involved in this
sort of thing before. See

https://datatracker.ietf.org/doc/draft-eastlake-2606bis/
https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/
https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/

At one early point I considered the addition of a number of additional TLDs
for testing purposes to the draft that became RFC 2606 including, as I
recall, one that was 63 octets long and a number 2-letter codes taken from
the permanently unassigned 2-letter ISO country codes. John Postel rejected
such efforts and in particular, if I recall correctly, indicated that as
IANA (at the time when essentially all registries were Expert Review and
John was the universal expert) he would reject any effort to assign any DNS
use to any ISO 2-letter code, other than as a national country code, unless
a liaison was received from ISO explicitly permitting such use regardless
of public statements by ISO that ISO would not assign a use to such any or
all such code in the future. That may have been an earlier era but I think
John Postel's position should still have some weight. And I would note that
more recently, the IESG has wanted a liaison to be crystal clear about
permissions from other standards development organizations for anything
that is at all questionable.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Fri, Apr 16, 2021 at 11:18 AM Paul Hoffman <[email-masked]>
wrote:

> 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_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Apr 2021 07:24:11 -0400

Hi Donald,

On 27 Apr 2021, at 22:34, Donald Eastlake <[email-masked]> wrote:

> I am not comfortable with grabbing all the permanently unassigned 2-letter country codes for DNS private use.
> 
> Note: I was the primary author of RFC 2606 and have been involved in this sort of thing before. See
> At one early point I considered the addition of a number of additional TLDs for testing purposes to the draft that became RFC 2606 including, as I recall, one that was 63 octets long and a number 2-letter codes taken from the permanently unassigned 2-letter ISO country codes. John Postel rejected such efforts and in particular, if I recall correctly, indicated that as IANA (at the time when essentially all registries were Expert Review and John was the universal expert) he would reject any effort to assign any DNS use to any ISO 2-letter code, other than as a national country code, unless a liaison was received from ISO explicitly permitting such use regardless of public statements by ISO that ISO would not assign a use to such any or all such code in the future. That may have been an earlier era but I think John Postel's position should still have some weight. And I would note that more recently, the IESG has wanted a liaison to be crystal clear about permissions from other standards development organizations for anything that is at all questionable.

Thank you for that. I think that's helpful.

There is much that is anecdotal and surprisingly informal in the way that decisions around top-level domains are made, and it is not surprising to me that this topic is difficult to address as an engineering problem.

The current co-editors of this draft are not in tight agreement about the correct path forward. One of us, in fact, (not me) is waiting for public, crystal clarity from ISO about their future plans, for example. We have asked the working group in past meetings what their preference is, but I don't think we asked clearly, one of the presenters had connectivity issues during the working group slot, etc. The document is not currently clear on its approach and it is unsurprising that people are expressing a variety of discomfort.

Personally, I favour the approach that if the IETF has anything useful to say it should minimise the scope of its pronouncements with the goal of balancing useful engineering with the avoidance of politics. My suggestion was that there is a logical argument here that doesn't involve assignment ("grabbing") but is still useful. Here it is:

1. Certain ISO-3166-2 codepoints are designated as being for private use by ISO and will not be assigned for use by countries, economies, etc;

2. Those ISO-3166-2 codepoints continue to be used for correspondingly-private applications in a variety of applications that have nothing to do with the DNS, so the designation from (1) is recognised and widely used;

3. ICANN does not assign two-character labels as TLDs except by reference to ISO-3166-2;

4. Use of ISO-3166-2 private-use codepoints will not clash with any TLD assigned for use in the public DNS.

[So far all we have done is made reference to other organisations' policies and observations about how those policies are used. We have not assigned or recommended anything.]

5. Since the policies referred to by (1) and (3) have existed for some time in the past, it is possible that people have used these codepoints as private-use TLDs, and (perhaps more importantly) we cannot know that they have not been used in this way;

[This argument makes no assumptions about ICANN or ISO policy in the future; it simply observes that certain policies have existed in the past.]

6. Collisions between private-use namespaces and the public DNS namespace are harmful;

7. The IETF restricts future use of these code-points in protocols in order to avoid the possibility of collisions: the public DNS namespace should not include these code-points.

This argument, I think, opens the door for the IETF to say something useful but does not need to predict future policy decisions by other organisations or impinge on any other organisation's policy agenda: the IETF retires code-points all the time because they have been burnt in the wild, and this is just another example.

I think even without declaring these code-points to be assigned for private use in the DNS, such a document would be sufficient to document their use for that purpose and to be explicit that such use will continue to be possible and safe from collisions with the public DNS namespace.

As I mentioned earlier, this is just my opinion of how to proceed. The current draft contains a mixture of various approaches and the result, I think, is unsatisfying. I am very prepared to be wrong here, however, and I am trying hard to express myself without pushing any particular agenda :-)

Joe

---

From: Roy Arends <[email-masked]>
Date: Wed, 28 Apr 2021 13:24:48 +0100

Hi Donald,

> On 28 Apr 2021, at 03:34, Donald Eastlake <[email-masked]> wrote:
> 
> https://datatracker.ietf.org/doc/draft-eastlake-2606bis/ <https://datatracker.ietf.org/doc/draft-eastlake-2606bis/>
> https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/ <https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/>
> https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/ <https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/>
> At one early point I considered the addition of a number of additional TLDs for testing purposes to the draft that became RFC 2606 including, as I recall, one that was 63 octets long and a number 2-letter codes taken from the permanently unassigned 2-letter ISO country codes. John Postel rejected such efforts and in particular, if I recall correctly, indicated that as IANA (at the time when essentially all registries were Expert Review and John was the universal expert) he would reject any effort to assign any DNS use to any ISO 2-letter code, other than as a national country code, unless a liaison was received from ISO explicitly permitting such use regardless of public statements by ISO that ISO would not assign a use to such any or all such code in the future.

Ack. See https://datatracker.ietf.org/liaison/1720/ <https://datatracker.ietf.org/liaison/1720/> to solicit that effect.

> That may have been an earlier era but I think John Postel's position should still have some weight.

I agree.

> And I would note that more recently, the IESG has wanted a liaison to be crystal clear about permissions from other standards development organizations for anything that is at all questionable.

I agree. 

Asking the ISO for a clarification in the form of a liaison statement is an important first step. It indicates that the IETF is aware of these specific UA code elements, and is willing to ask clarification on them, and respects the organisation responsible (the ISO) for these code elements. Following established diplomacy between the IETF and the ISO on this specific matter is IMHO preferable and more inclusive over either sitting in fear and do nothing, because “ISO or IANA may get upset if we (the IETF) do this", or worse, that an emboldened IETF DNSOP WG unilaterally decides that these elements are just like “code elements” and should be “retired” (put on a "do not delegate” list), which IMHO would create unnecessary frustration between various organisations.”

The liaison ( https://datatracker.ietf.org/liaison/1720/ <https://datatracker.ietf.org/liaison/1720/>  ) send by the IAB to the ISO is IMHO a clear indication that a path of diplomacy is preferred over unilaterally retiring code elements.

The working group can (after a potential clarification from the ISO about the future status of code elements) decide if a subset suffices and if so, the composition of the subset.

Warmly,

Roy

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 28 Apr 2021 14:29:34 +0200

Let me make some pedantic remarks about the terms used in this
discussion.

 Joe Abley writes:

  > 1. Certain ISO-3166-2 codepoints are designated as being for private
  > use by ISO and will not be assigned for use by countries, economies, etc;

What you mean here is the ISO 3166 Part 1 (ISO 3166-1 Country codes)
and just the "alpha-2" codes (two letters).

    [Part two from ISO 3166 is about subdivision codes. Subdivision
    codes in Part 2 consist of alpha-2 country codes, hyphen and one or
    more characters (as in AU-QLD for Queensland).]

 > 2. Those ISO-3166-2 codepoints continue to be used for
 > correspondingly-private applications in a variety of applications
 > that have nothing to do with the DNS, so the designation from (1) is
 > recognised and widely used;
 >

The ISO 3166 term forthese code points is "User Assigned".

Regards,

	jaap

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Apr 2021 08:35:00 -0400

> Let me make some pedantic remarks about the terms used in this

Thanks Jaap, I welcome the accuracy :-)

Joe

---

From: Jim Reid <[email-masked]>
Date: Wed, 28 Apr 2021 13:38:26 +0100

> On 28 Apr 2021, at 13:24, Roy Arends <[email-masked]> wrote:
> 

I agree with this approach.

IMO it’s reasonable for the WG to produce an RFC which says “If you need a TLD for private use, pick from the two letter codes that ISO 3166 MA says they’ll never allocate. Bear in mind if they later change their mind, you’ll be on your own and could well be in a world of pain. Have a nice day.”.

---

From: David Conrad <[email-masked]>
Date: Wed, 28 Apr 2021 17:42:55 -0700

Hi,

> IMO it’s reasonable for the WG to produce an RFC which says “If you need a TLD for private use, pick from the two letter codes that ISO 3166 MA says they’ll never allocate. Bear in mind if they lat…

I’d agree, with the slight modification of:

“…  if they later change their mind, you and any of the unmeasurable number of folks who happened to listen to ISO-3166/MA regarding the status of the user assigned codes will be on your own and could well be in a world of pain.”

(Only half :) — the reality is that lots of folks use the user assigned codes for all sorts of reasons and if they’re repurposed, it’s probably going to be a mess).

Regards,
-drc
(Speaking for myself)

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 29 Apr 2021 00:53:17 +0000

> IMO it’s reasonable for the WG to produce an RFC which says “If you need a TLD for private use, pick from the two letter codes that ISO 3166 MA says they’ll never allocate. Bear in mind if they lat…

s/world of pain/world of pain until you choose a new name that remains unused/.

We have no hard evidence that squatting on an unused TLD that is later put in the root zone causes more than annoyance. (This is where our illustrious AD chimes in with some examples from the round of 2012, and I again, exasperatedly, tell him that while those are true cases, they appear to be merely annoyances and ask him for evidence otherwise, and he retorts that it is I who needs to prove my point, not him, and we all sigh and wait another few years before we repeat this.)

--Paul Hoffman

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 28 Apr 2021 22:52:05 -0400

Hi,

On Wed, Apr 28, 2021 at 8:24 AM Roy Arends <[email-masked]> wrote:

> At one early point I considered the addition of a number of additional
> TLDs for testing purposes to the draft that became RFC 2606 including, as I
> all such code in the future.
>
>
> Ack. See https://datatracker.ietf.org/liaison/1720/ to solicit that
> effect.
>

My apologies for being unaware of that liaison.

If ISO says it's OK, then I have no objection to recommending that some of
these private use 2-letter codes be used for local DNS zones. But if they
are good for this use with reference to the DNS, then I don't see why it
might not turn out some day there is some different good use for them. So I
would pick half of them and just recommend those.

Thanks,
Donald

> And I would note that more recently, the IESG has wanted a liaison to be
> crystal clear about permissions from other standards development
> organizations for anything that is at all questionable.
>
>
> I agree.
>
> Asking the ISO for a clarification in the form of a liaison statement is
> an important first step. It indicates that the IETF is aware of these
> specific UA code elements, and is willing to ask clarification on them, and
> respects the organisation responsible (the ISO) for these code elements.
> Following established diplomacy between the IETF and the ISO on this
> specific matter is IMHO preferable and more inclusive over either sitting
> in fear and do nothing, because “ISO or IANA may get upset if we (the IETF)
> do this", or worse, that an emboldened IETF DNSOP WG unilaterally decides
> that these elements are just like “code elements” and should be “retired”
> (put on a "do not delegate” list), which IMHO would create unnecessary
> frustration between various organisations.”
>
> The liaison ( https://datatracker.ietf.org/liaison/1720/  ) send by the
> IAB to the ISO is IMHO a clear indication that a path of diplomacy is
> preferred over unilaterally retiring code elements.
>
> The working group can (after a potential clarification from the ISO about
> the future status of code elements) decide if a subset suffices and if so,
> the composition of the subset.
>
> Warmly,
>
> Roy
>
>

---

From: Matthew Pounsett <[email-masked]>
Date: Thu, 29 Apr 2021 20:09:01 -0400

> That's correct, as it would be for any private-use TLD. In fact, it's not just about validating stubs: an organization wanting to use a private-use TLD cannot have validating stub resolvers or vali…

* Unless they configure the appropriate exceptions into those resolvers/stubs.
(Spoken as someone who has set up validating resolvers inside an
enterprise camping on an unregistered TLD for use in AD).