[dns-operations] TLD(s) for private use

Andrew Sullivan ajs at anvilwalrusden.com
Wed Sep 6 12:21:57 UTC 2017


On Wed, Sep 06, 2017 at 12:22:23PM +0100, James Stevens wrote:
> Alpha-2: AA, QM to QZ, XA to XZ, and ZZ

[…]

> This seems to confirm, from a purely ISO perspective, ZZ would be safe to
> use.

The reservation of ZZ appears to be safe for now..  I will note that
CS was widely considered to be "safe" from re-assignment when it was
retired for Czechoslovakia, but it was assigned to Serbia and
Montenegro; that assignment is now also gone and the whole thing is
supposed to be reserved until 2056.  It is important to remember that
ISO3166/MA is dealing with the UN.  Member nations of the UN are not
always patient with technical reasons why "their" code is not
available, which is presumably how CS ended up handled the way it was.

> Might I suggest it would be useful to have a guaranteed reserved (say)
> prefix, like "zz--"

Why?  Why do you need a top level domain for this at all?

> The "fear" I have with this technique is that there is the /potential/ for
> the data to get out into the public domain, as its hosted in a publicly
> accessible TLD.

There is the potential for this _no matter what_.  There is no way to
guarantee that queries won't leak.  People have been relying on that
forlorn hope for years, but it is an error.

> A TLD that is not in the ROOT zone gives an added level of comfort -
> especially for those higher up the management chain for whom an
> understanding of the DNS might be less clear.

To state that less charitably, it seems like you are suggesting that
the unified-root structure of the DNS is supposed to have additional
pointless warts on it in order to make ignorant managers happy.  I am
not convinced that is a goal for which we ought to fool with the
structure of a globally shared resource.

> updating - but it may be carrying data that I wouldn't want in the public
> domain.

Then it is the wrong tool for your job.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com



More information about the dns-operations mailing list