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

[Chris Lee]

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

https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx

"
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>