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

[Petr Špaček]

On 6.9.2017 12:18, Jim Reid wrote:
> 
>> On 6 Sep 2017, at 10:28, James Stevens <James.Stevens at jrcs.co.uk> wrote:
>>
>> Apart from those in RFC-6761, is there any TLD, or format of TLD, that can be used for private use that is guaranteed never to be allocated?
> 
> No.
> 
> There's just no way of knowing for sure what names IETF might one day add to a reserved list. Or what TLD strings will or won't get created by ICANN. If you are able to do that, your talents could be put to better use buying winning lottery tickets in advance.

Let me add more reasoning why using *any* string you do not own is
BAD IDEA:

Reserving a string does not solve the problem if two companies using the
string need to cooperate. Imagine a VPN between companies (customer
using VPN to supplier's network, for example), or the event where two or
more companies get merged, etc.

If we reserved string 'example.', how it helped to solve the problem
when your company X needs to establish VPN tunnel to company Y internal
network to access its systems?


Creating subdomains under the reserved name does not help because it
just lowers the probability but does not avoid the conflict.

How does it help if company X merges with company Y and both were using
internal domain int.example. (e.g. because "int" is short)?


Really, unique strings are the only safe way to go. Any domain for few $
a year will be good enough. Use i.<yourdomain.com.> and be done with it.

(Please note that the DNS servers responsible for i.<yourdomain.com.> do
not need to answer to addresses outside of your internal network.)


The practice of relying on names delegated to you is already recommended
by vendors. E.g. Red Hat recommends it from 2014. See

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Configure_Host_Names.html#sec-Recommended_Naming_Practices


I hope it helps.

-- 
Petr Špaček  @  CZ.NIC