> In response to the report, ICANN labeled the .home and .corp strings as "high risk" and proposed that neither of the strings be delegated until it could be proven that risk is low. These two strings are currently severely delayed and some community members guess they may never be delegated.
>Recommendation (2) of SAC 045 calls for the community to develop principles for "prohibiting the delegation of additional strings to those already identified in RFC2606 [RFC2606]." As the first step in that process, based on the data reported by SAC 045, this document adds to the list of names that may not be used for top-level domains the following labels:
Presumably this client insisted upon this silly idea over your objections?
Because if this was _your_ idea then if I were the client I'd feel like I hired somebody who was totally incompetent when I find out this arbitrary name they picked for me is a dumpster fire.
You're quoting an _expired_ _draft_ document as if that's some sort of standard.
Note that the document the parent cites is a draft standard that was due to expire in December 2011. Also, it recommends reserving .local, which subsequently was assigned to Multicast DNS.[0] I'm not a DNS expert, but I don't know if I'd count on it.
Wow, I think I need a shower to wash off the arrogance that came from just reading that page. I'd agree in premise, but officially, not even ICANN owns them; they only manage them. You shouldn't use them because of plenty of reasons. But you're totally allowed to, sysadmins everywhere will just hate you.
Back in 2000, there was an IETF Internet-Draft entitled DNS Top Level Domain For Private Networks[0] that recommended using .pri:
"A reserved top level domain name, '.pri', would allow a private domain name to be chosen safely with no risk of conflict with current or future registered domain names. A private DNS server is configured as authoritative for the '.pri' domain, and delegates the private subdomains as appropriate."
It sadly was never picked up[1].
Over the years, Microsoft has recommended and in some instances even forced[2] the use of .local, which they now advise against[3].
Though the interesting answer to why Microsoft now has to advise against .local is that RFC 6762 reserved it as a special-case for Multicast DNS (mDNS fka Bonjour and a bunch of other names).
If the company owns a public domain name, it has an entire subtree of names that it controls and can use, employing split horizon DNS service, for the office LAN.
So am I reading that right? A significant number of people are using .home and .corp as the TLD for their local or internal network domains, so ICANN decided to (possibly indefinitely) delay delegation of those TLDs?
Yes, for these particular suffixes the problem is considered insurmountably bad, they're basically poisonous.
For a while Microsoft was telling companies to use .corp internally, these days their advice warns against this, but good luck getting a huge company to change anything in less than a lifetime.
When I say these names are poisonous I mean that in two senses
1. A tremendous number of people can't resolve your name in this suffix. Many of them won't know why, and can't really be expected to "fix" the problem.
2. Name servers for these suffixes receive a tremendous amount of "bogus" traffic that leaked from people who used these names but didn't properly seal them off from the Internet. Serving this traffic costs money.
Now, we recently saw for 1.1.1.1 that something so badly abused as to be poisonous can be reclaimed anyway if the people using it go in with their eyes open. I'd liken this to the practice of marking low value areas known to have some unexploded munitions buried as unsafe for humans and letting people run sheep, goats or cattle on that land on the understanding that (1) under no circumstances are people to enter and (2) sometimes an animal will explode, that's too bad, but hey the land was rent-free and would otherwise be useless. But just selling off land with unexploded munitions for building a new housing estate is clearly negligent.
> Now, we recently saw for 1.1.1.1 that something so badly abused as to be poisonous can be reclaimed anyway if the people using it go in with their eyes open
> There is an existing process for allocating names under '.arpa.' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone.
