Subject: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

From: "John Levine" <[email-masked]>
Date: 28 Sep 2016 23:27:20 -0000

I don't think this has anything to do with RFC 6761, so ...

For a very long time, two letter TLDs have been assigned to countries
and other geographic entities per the ISO 3166 alpha-2 list.  The
earliest mention I can find is in RFC 920 in 1984, and even then the
wording suggests that the usage was well settled.

The codes AA, QM-QZ, XA-XZ, and ZZ are "user assigned" and will never
be used for countries.  Last year Ed Lewis wrote an I-D proposing that
XA-XZ be made private use and the rest future use, but as far as I can
tell it never went anywhere.

I've been telling people that if they need a fake private TLD for their local
network they should use one of those since it is exceedingly unlikely
ever to collide with a real DNS name.  Am I right?

R's,
John

PS: On my lan, I'm using .QY.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Sep 2016 10:07:47 +1000

> ever to collide with a real DNS name.  Am I right?

No.  Just because countries don't get assigned these values it
doesn't mean that they can't be assigned by ICANN or the IETF in
consultation with ICANN.

And who *needs* a fake tld?  As far as I can tell almost no one.
None of the companies using .CORP do.  You can't use a .corp.example.com
or similar?

Now it may be nice to have a tld and for somethings you need a well
known namespace to play in (.onion, homenet (location TBD)).

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 28 Sep 2016 18:53:04 -0700

John,

On September 28, 2016 at 4:27:51 PM, John Levine ([email-masked]) wrote:

I don't think this has anything to do with RFC 6761, so ... 
I tend to agree, but it did get caught up in the 6761 maelstrom

6761 "discussions" sidetracked it I believe.

I'd really like to say yes, but ISO-3166/MA appears to have removed references to "User Assigned" in their official ISO-3166 two letter code webpage. I'm trying to understand if they've changed their mind, but no answer yet.

Regards,
-drc

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2016 22:23:31 -0400

> I've been telling people that if they need a fake private TLD for their local
?? network they should use one of those since it is exceedingly unlikely
?? ever to collide with a real DNS name. Am I right?
??
> I'd really like to say yes, but ISO-3166/MA appears to have removed references to "User Assigned" in their official ISO-3166 two letter code webpage. I'm trying to understand if they've changed the…

The current list on the ISO web site completely omits those codes. 
They're not assigned, they're not unassigned, they're not reserved, 
they're not formerly assigned, they're not anything.

For about $40 one can buy a copy of ISO 3166-1:2013.  It's not clear from 
the TOC if it's any more informative.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 29 Sep 2016 02:53:51 -0000

>doesn't mean that they can't be assigned by ICANN or the IETF in

I don't see how that follows.  For over 30 years, the rule has been
that two-letter names are reserved for ccTLDs.  There's never been any
hint in any RFC I have found that any two-letter names can be assigned
in any other way.

>And who *needs* a fake tld?

Nobody.  We could use HOSTS.TXT.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Sep 2016 14:17:48 +1000

> hint in any RFC I have found that any two-letter names can be assigned

Things can change.  It is ALWAYS a bad idea to use namespace not
delegated to you.

> Nobody.  We could use HOSTS.TXT.

hosts.txt still takes domain style hostnames.  This is a namespace
issue not a resolution mechanism issue.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Sep 2016 05:42:46 +0000

On 9/29/16, 03:27, "DNSOP on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

> Last year Ed Lewis wrote an I-D proposing that XA-XZ be made private use and the rest future use, but as far as I can tell it never went anywhere.

I'd been waiting for anyone else to show an interest in it before spending any time on it.  This is the first mention I've seen on a public list about the draft. ;)

As David wrote in a later message, the dam burst on Special Use Domain Name registry discussions.
   
>I've been telling people that if they need a fake private TLD for their local network they should use one of those since it is exceedingly unlikely ever to collide with a real DNS name.  Am I right?
    
I'd have to say not right to be "telling people".  The one option you have is ".example", unfortunately (and in sympathy) I don't have a better suggestion.

Heuristically, you might be okay using these codes but it's that same-old-same-old problem of assuming the future.  My preference would be to put the appropriate codes in to the Special Use Domain Name registry before "telling people".  I stress the "telling people" because you using ".qy" isn't ever going to come to harm (because you can change that "if").

BTW, the user assigned two-letter codes are not the same as unassigned codes. These have been expressly set aside for local use, these codes aren't eligible for use in any other way, no matter what a new region might call itself.  That is, it's more likely some other novel use for one of these codes might be found than the code ever matching an economy's identifier.

---

From: hellekin <[email-masked]>
Date: Thu, 29 Sep 2016 06:56:51 +0000

On 09/29/2016 05:42 AM, Edward Lewis wrote:
>     
> The one option you have is ".example", unfortunately (and in sympathy)
> I don't have a better suggestion.
>

.example is for documentation.  You can use .invalid for "fake private
TLD", which makes it very clear that it's not a valid TLD. (Sorry for
the tautology.)

This list of two-letter TLDs sounds like a good candidate for
Special-Use Domain Names.  But then, it prompts another question: if,
e.g., XA-XZ are reserved for future use, how to handle their *removal*
from the Special-Use Name Registry once they're assigned again?  Which
prompts another question: if a name enters the Special-Use Name
Registry, is it parked (for an indefinite amount of time), or is it
engraved in stone (and won't move from that registry again)?  And can
the SUNR hold both types of names (parked and final)?

==
hk

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 29 Sep 2016 09:37:19 +0200

David Conrad writes:

 > 
 > I'd really like to say yes, but ISO-3166/MA appears to have removed references
 > to "User Assigned" in their official ISO-3166 two letter code w=
 > webpage.

Only the the standard is normative.

 > I'm trying to understand if they've changed their mind, but no answer yet.

The standard hasn't changed in that reqpect for the last twenty five year of so.

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 29 Sep 2016 09:47:48 +0200

> the TOC if it's any more informative.

The rules are in Section 8.1.3:

	If users need code elements to represent country names not
	included in this part of ISO 3166, the series of letters
	AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ,
	QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively, and
	the series of numbers 900 to 999 are available.

	NOTE Users are advised that the above series of codes are
	not universals, those code elements are not compatible
	between different entities.

I vaguely remember that Ed Lewis is quoting o paraphrasing the same
thing in his draft

	jaap

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Sep 2016 07:56:22 +0000

> ever to collide with a real DNS name.  Am I right?

The the ".invalid" TLD is reserved, and has been used for private
naming of domains that are sure to not be real domains either
internally or on the public Internet.  I use:

  address.invalid - added to bare mailbox names in inbound external email.
  bcc.invalid - rewrite domain for (env recipient data) lossless Bcc copies of email
  discard.invalid - rewrite domain for addresses whose email gets dropped.
  local.invalid - rewrite domain for local delivery when no real domain is "local"
  ...

This is of course different from squatting on a TLD for naming
"real" private domains, and I see little justification for the
latter.  Real 2LDs, 3LDs, ... are cheap, and why not use those
instead?

And for documentation we of course have ".example", "example.net",
...

-- 
	Viktor.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 29 Sep 2016 06:37:16 -0400

> On Sep 29, 2016, at 2:56 AM, hellekin <[email-masked]> wrote:
> 

Good question, not (as far as I know) explicitly addressed in RFC 6761.

Because there is no explicit prohibition on removal of a name from the SUNR, publication of an appropriate RFC directing IANA to take such an action would be the appropriate action, at least. In my opinion.

The question might actually apply to many IANA registries.  Do the "Registration Procedures" apply to "unregistration" as well?  I don't know if there is any precedent here.

- Ralph

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 29 Sep 2016 09:28:24 -0400

It wasn't particularly clear which later message in this thread to respond
to so I'm replying to the first. If anyone is interested, I happen to know
John Postel's opinion on this matter. If you look at early drafts of RFC
2606, such as
https://www.ietf.org/archive/id/draft-ietf-dnsind-test-tlds-06.txt
you will see a lot more tld's including some of these reserved country
codes. John reject all those saying that, regardless of what the ISO
standards currently said, the IETF couldn't constrain any two letter tld's
without a clear prior agreement from ISO.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: David Conrad <[email-masked]>
Date: Thu, 29 Sep 2016 08:23:57 -0700

Mark,

No. Just because countries don't get assigned these values it 
doesn't mean that they can't be assigned by ICANN or the IETF in 
consultation with ICANN. 
I believe from both the IETF's and ICANN's perspective, 2-letter labels at the root are reserved to be associated with ISO-3166 2-letter codes. I cannot imagine a plausible scenario in which this policy would change.

And who *needs* a fake tld? As far as I can tell almost no one. 
Can we PLEASE not repeat the arguments made against RFC 1918 space in the domain name world?

Regards,

-drc

---

From: "John Levine" <[email-masked]>
Date: 29 Sep 2016 15:32:41 -0000

>Good question, not (as far as I know) explicitly addressed in RFC 6761.

It isn't.  Given what's in 6761, I doubt the question ever came up.

>if there is any precedent here.

Well, the list of names in the root is nominally an IANA registry, and
they're removed lots of names such as .NATO and countries that no
longer exist such as .CS and .YU.  But somehow I'm guessing that's not
what you're thinking of.

It is my vague recollection that we have removed some old cruft from parameter
registries, but after some googlage I can't find any details.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Thu, 29 Sep 2016 08:44:00 -0700

Mark,

On September 28, 2016 at 10:35:40 PM, Mark Andrews ([email-masked]) wrote:

Things can change. It is ALWAYS a bad idea to use namespace not 
delegated to you. 
Unless, of course, Ed's draft progresses and the user assigned ISO codes are turned into private use TLDs (similar to RFC 1918 turning 10/8, etc., into private use address space).

The only way the user assigned codes could be delegated would be if:

a) ISO reverses their policy for those codes and assigns them to countries

b) The IETF revises name assignment policy and demands they be delegated 

c) The ICANN community revises name assignment policy and allows them to be delegated

I'm quite confident that (c) will never occur -- too many parts of the ICANN community would reject the idea instantaneously and given the new gTLD program, there is simply no reason for the question to even come up.  Similarly, I'm reasonably confident the IETF won't demand those labels be delegated -- I can't see a reason why a different solution would be sufficient. Where I don't have as much confidence is in ISO-3166/MA's actions, but that's mostly because I don't know how they work.

Regards,

-drc

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Sep 2016 12:03:41 -0400

> I'd have to say not right to be "telling people".  The one option you have is ".example", unfortunately (and in sympathy) I don't have a better suggestion.

I (and a few others) had considered writing a document requesting that
.internal be reserved according to 6761, but:
A: that process is currently closed and we were asked to not make any
new suggestions until (at least) the SUN problem statement was adopted
settled.
B: it was unclear why a whole separate draft was needed and not just
add some text to draft-ietf-dnsop-alt-tld, saying .alt for alternate
name resolutions and .internal for names which use the DNS, but are
not part of the global DNS space
and
C: why not just use .alt for this? It is clear that these should not
hit the global DNS, and should fail (get NXD) if they do. It is
clearly different to a ccTLD (at least some users have learnt that
things of the form .xx are "countries" - lets not confuse them
further).

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Michael StJohns <[email-masked]>
Date: Thu, 29 Sep 2016 12:42:42 -0400

Hi -

A couple of items of history.  Back about 1987, Jon Postel and I talked 
about the original registration of .INT - he was the IANA, I was 
managing the NIC contract which would be responsible for dealing with 
registrations under .INT.  ( .INT ended up being managed by ISI under an 
DARPA contract when the DDN PMO wouldn't cover the costs).  The topic of 
the cc TLDs came up then and strangely a bit later when I was at 
(D)ARPA.  The first time was a discussion about .UK vs .GB, the last was 
about Native American tribes/nations.

Jon was adamant (and I think rightly so) about keeping the IANA out of 
determinations of "what is a country"  and to use the 3166 process for 
allocation of 2 character TLDs (note I didn't say ccTLDs) and I think 
that still makes a lot of sense.  Given that, I would suggest we say 
that all of the possible two letter TLDs not yet delegated have been 
reserved by the IANA on behalf of ISO3166 pending a request to delegate 
them to an entity identified by ISO3166.  I might suggest that 
ICANN/IANA update RFC1591 to discuss how to deal with "transitionally 
reserved" TLDs/ISO3166-2 codes (e.g. .SU from the soviet union for 
example) if they haven't already.

And to answer John's original question - it's probably a bad idea, but, 
like smoking,  it probably won't kill you immediately.  I might actually 
suggest using .EZ which looks like it will never be stood up as a DNS 
domain given that its registration is for " European OTC 
<https://en.wikipedia.org/wiki/Over-the-counter_%28finance%29> 
derivatives within International securities identification numbering 
system 
<https://en.wikipedia.org/wiki/International_Securities_Identifying_Number> 
(ISIN)"

And to go back to Ed's comment.  I *wouldn't* move forward with his 
draft.  It's not space that's currently owned by the IETF/IANA/ICANN.

So a big +1 to Mark's comment about using namespaces not delegated to you.

Mike

On 9/29/2016 11:44 AM, David Conrad wrote:
> Mark,
>
> On September 28, 2016 at 10:35:40 PM, Mark Andrews ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
> Unless, of course, Ed's draft progresses and the user assigned ISO 
> codes are turned into private use TLDs (similar to RFC 1918 turning 
> 10/8, etc., into private use address space).
>
> I'm quite confident that (c) will never occur -- too many parts of the 
> ICANN community would reject the idea instantaneously and given the 
> new gTLD program, there is simply no reason for the question to even 
> come up.  Similarly, I'm reasonably confident the IETF won't demand 
> those labels be delegated -- I can't see a reason why a different 
> solution would be sufficient. Where I don't have as much confidence is 
> in ISO-3166/MA's actions, but that's mostly because I don't know how 
> they work.
>
> Regards,
>
> -drc
>
>
>

---

From: "John R Levine" <[email-masked]>
Date: 29 Sep 2016 17:37:49 -0400

> things of the form .xx are "countries" - lets not confuse them

I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for 
fear of, if you'll pardon the phrase, name collisions.

Regards,

---

From: william manning <[email-masked]>
Date: Thu, 29 Sep 2016 15:04:44 -0700

On Thursday, 29 September 2016, John R Levine <[email-masked]> wrote:

> I've been telling people that if they need a fake private TLD for their
>>>> local network they should use one of those since it is exceedingly unlikely
> https://www.ietf.org/mailman/listinfo/dnso
> <https://www.ietf.org/mailman/listinfo/dnsop>
>

Name collisions may occur at any delegation point - why do you think the
root zone is special in this regard?