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

[Jim Reid]

> On 6 Sep 2017, at 15:28, James Stevens <James.Stevens at jrcs.co.uk> wrote:
> 
> Many are well aware of the RFC1918 IPs for use on a private LAN.

And look how that turns out when two organisations both using 10/8 (say) merge or otherwise interconnect their networks. If you want unique identifiers (domain names, IP addresses, whatever), use identifiers that you *know* are yours and only yours. It's that simple.

> Domains with no NS in the parent zone become harder to discover & get data about. This is true of any sub-domain in a TLD, but registering a name for that purpose involves (1) an annual cost & risk this will fail to be done at some point and (2) finding a registrar who will allow this.

Nope. Once any registrar registers your domain name, you can do whatever you want with it, including subdelegations. And the "annual costs & risks" of plucking an arbitrary name out of the ether and hoping nobody else will ever use it will be even higher. The actual issue above is documenting the configuration, identifying the risks and threats as well as the rationale for doing it. Provided that's done properly, all will be well. Famous last words...

> Creating a sub-domain in a domain that was used for something else, would likely create confusion for future engineers, in a way that (say) a universally known "unregistered" prefix like "zz--" would not - in the same way that all network engineers understand the implications when they see an RFC1918 IP.

I think your assumptions here are wrong. It is a *huge* mistake to assume a universally known "unregistered" prefix could work in that way. [How would you know about my zz--james and how would I know about yours?] That's just like how many network engineers fail to understand the implications of using RFC1918 IP addresses. The way to avoid the confusion you've mentioned is to properly document the organisation's naming and addressing policies and fully assess their risks/threats.

> There can often be information some operating systems automatically put in their DNS you wouldn't want in the public domain.

So don't do that. It's trivial to make sure that sensitive data does not get added to public-facing DNS servers. In fact, these setups are very common in corporate environments. What's visible in the intranet for foo.com (and who gets access to it) is *very* different from what's presented on the Internet version of foo.com.