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

Chris Lee chris at datachaos.com.au
Thu Sep 7 14:56:53 UTC 2017

Indeed AD was still relatively green in 2003, times change and so has best


Dummy DNS name vs official DNS name

In the past, lots of people chose to use a dummy, unofficial TLD
(top-level-domain) for their internal network, like domain.*lan*, domain
*.local* of domain*.internal* (and also domain.internalhost)

But this can get you in serious trouble. Because these names are not
supported by internet standards, the most important RFC on this is: RFC
2606 [image: Jump] <http://tools.ietf.org/html/rfc2606>(
http://tools.ietf.org/html/rfc2606 [image: Jump]
<http://tools.ietf.org/html/rfc2606>) This RFC standard is very explicit on
choosing domain names for private testing and documentation"

Microsoft sum it up very succinctly today for anyone contemplating a fresh
AD domain...

"Microsoft strongly suggests to work with subdomains, within a publicly
registered TLD domain. Check: Creating Internal and External Domains op
https://technet.microsoft.com/en-us/library/cc755946(WS.10).aspx [image:
Jump] <https://technet.microsoft.com/en-us/library/cc755946(WS.10).aspx>"

On Fri, 8 Sep 2017 at 00:23, James Stevens <James.Stevens at jrcs.co.uk> wrote:

> >> It would be interesting to hear from a ROOT server operator (or two), or
> >> somebody who has looked at the OARC DITL data, to know what proportion
> >> of ROOT query traffic might be the result of TLD squatting.
> >
> > ICANN commissioned a report (and followup studies) on that very topic in
> 2013:
> >
> >
> https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf
> Thanks - very useful.
> A quick skim suggests this was aimed very much at looking for a specific
> range of collisions, although that did include some Vendor defaults - as
> opposed to looking at the issue in a more general sense - which I
> understand is very difficult for all sorts of reasons.
> Not least because, now the internet has such a large mobile contingent,
> the simple typo of "." instead of SPACE is starting to be quite a big
> issue.
> "Using “Private” Top-Level Domains
> In Windows 200x, you can create your own top-level domains for your
> internal networks. It’s a very good idea, when applicable, to create
> top-level internal domains that do not exist outside your internal
> network. Using a top-level domain such as .home or .work
> makes it difficult for users outside your network to resolve IP
> addresses for computers inside your private network, since these
> top-level domains do not exist in the public DNS system."
> Well, there you have it - And that's in a training manual for MSCE -
> admittedly for Server 2003! At least they put "private" in inverted commas.
> https://books.google.co.uk/books?id=Z-zLkifsnXoC&pg=PA5&lpg=PA5&dq=%22Using+a+top-level+domain+such+as+.home+or+.work%22&source=bl&ots=JhWEfrghXs&sig=oiryNe7zKgZ7A6AId5rXrr3YaFw&hl=en&sa=X&ved=0ahUKEwiTvtzpnJPWAhXmIsAKHbTxBtMQ6AEIKDAA#v=onepage&q=%22Using%20a%20top-level%20domain%20such%20as%20.home%20or%20.work%22&f=false
> ... and, from the report itself ...
> "Widely adopted industry practices for the development of enterprise
> network naming schemes have long promoted the use of labels that are not
> delegated in the public DNS as top-level domain names."
> Given that statement, its hard not to say there is an issue.
> I would suggest, that wide spread rfc1918 use shows that *if* there had
> been an "official" way to have undelegated domains it would have been used.
> I suppose another solution would be to use a domain name that would be
> invalid in the public space, but OK for private use - like a "zz__"
> prefix? Would that be a viable alternative?
> I can't help feeling that NOTHING is truly "safe" to use, until there is
> something that is "officially" endorsed as safe to use.
> James
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations
> <https://lists.dns-oarc.net/mailman/listinfo/dns-operationsdns-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/ce520966/attachment.html>

More information about the dns-operations mailing list