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

Jothan Frakes jothan at gmail.com
Fri Sep 8 04:27:14 UTC 2017

tl;dr :   I suggest this... Try xx--[whateverword] to avoid most/many
future collisions       it takes advantage of the IDN blocking dashes at
the third and fourth positions and allows for things like xx--vpn or
xx--corp or xx--mshome etc which are human readable and won't trigger
namespace collisions.


The random gibberish TLDs that John suggested make sense, but could still
cause a future collision, no matter how unlikely.  I ran into some
instances where there were names I owned that I thought were random
gibberish that turned out were highly precious in the Chinese market a
couple years back, so it stands to reason that just because we don't
currently see a possibility of conflict, the universe seems to provide the
potential.  I guess even if it is made up, it is still violating ICP-3 and
could cause namespace collision in the future.

We may be kicking a name collision can down the road, though many of us
doubt it... I suspect that the wisest course would be to work inside the
space restricted from typical use in order to avoid the potential

I do have a suggestion.

If I can 'plus-up' Paul's great suggestion, and synthesize a few of the
ideas from the genius on list here, there is a restricted space of null
area that exists for IDN whereby names with dashes in the 3rd and 4th
positions are restricted.  You could, if you avoided xn--, put any other
two letters in front of a string then two dashes.

It also allows for more human readable strings as private space TLDs, like
xx--corp or xx--vpn instead of randomness, so in that sense it could be a
preferred approach.

[universe under fingernail stuff beyond this point]
As many of us have seen across the years, the ITU or others seeking to
introduce geodiversity into the authority of name structure, from time to
time.  In a conceptual conversation I had with some ... jedi over the
years, it was considered wise to stay in the sandbox of the private use
space of the ISO 3166 two char prefixes to avoid conflict with national
claims and/or compatibility with GACJackassery (not my term, but

This would reduce the likelihood of causing unintentional namespace
collision with a future gTLD to not just make up random strings willy
nilly.  I would suggest x[a-z]-- (but not xn-- so that one avoids IDN
collision), to avoid some future use of <iso3166>-- prefix for balkanized
national mapping that ITU or someone seeking to do might push on us through
law such as TLDs becoming somehow fractionally used geographically in some
manner using ccTLD dash dash prefixes (ie. us--com, ru--com, de--com,
cn--com being different or affected by some future tech that intervenes in

Jothan Frakes
+1.206-355-0230 <(206)%20355-0230> tel
+1.206-201-6881 <(206)%20201-6881> fax

On Thu, Sep 7, 2017 at 6:57 PM, Paul Vixie <paul at redbarn.org> wrote:

> John Levine wrote:
>> ...  I would wager
>> quite a lot that none of these TLDs will appear in the root zone in my
>> lifetime:
>> .hcdsjm
>> .dxozso
>> .pmlwat
>> .yoorzf
>> .usapqm
>> .miyepz
>> .tmokxs
>> .ytnhlv
>> .nvikrt
>> .mjjwsj
> i have an even safer wager. put a hyphen in it. say, x-randomstring.
> this is what led us to use .rpz-nsip and similar, in the rpz design.
> --
> P Vixie
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170907/0a3fc10b/attachment.html>

More information about the dns-operations mailing list