Really large ISPs have even planned for the disaster-recovery scenario of a collapse of public DNS infrastructure, so their internal management network and hostnames are not related to the existing gTLD or ccTLD, or legacy TLD in any way. There is no need to involve ICANN-approved TLDs in your internal DNS infrastructure, particularly if you have management interfaces for a lot of things that are firewalled off or air gapped from ever touching the public internet.

What does ICANN have anything to do with this? If the global DNS system crashed and burned, you would be in exactly the same place as if you had invented a TLD as you have suggested. But, if that doesn't happen... And the way more likely outcome of your "made up TLD" becoming real happens instead, you're in a way worse position.

So far I've read you suggest .taco, .burrito, and .burritocorp as good TLDs to pick. This is terrible advice.

Purchase a public domain name from a real TLD - use it knowing it's yours, and never going to conflict.

I'm using made up words as placeholders like foo, bar, or anything else. Not suggesting you use your own tld of burrito. The point of using a nonsensical example is that your TLD choice for hostnames and rDNS in a management VRF can be entirely arbitrary, since it is not part of "the internet".

Typically the name would be something relevant to your needs, such as the name of the company, or AS number. I think what you don't get is that the public root name servers do not need to have anything to do with an entirely internal dns infrastructure.

Not suggesting icann is going to crash and burn either, but that "real" TLD relevance to what you do in rfc1918 IP space in a network that is not routed to the internet is minimal at best.

Bet you $5 that Google's actual internal dns for the oob, SNMP management, automated provisioning tools which control those 1e100 hosts is not 1e100, and is not a zonefile you can find cached anywhere public. They built their own internal dns for it. Have seen the same at two large CDNs. Their internal authoritaive DNS servers for their management IP space have no connection whatsoever to the public internet or to the lettered root nameservers.

> I'm using made up words as placeholders like foo, bar, or anything else. Not suggesting you use your own tld of burrito. The point of using a nonsensical example is that your TLD choice for hostnames and rDNS in a management VRF can be entirely arbitrary, since it is not part of "the internet".

1.1.1.1 wasn't part of the internet either, and, guess what it does today?...

> and is not a zonefile you can find cached anywhere public

You seem to be conflating owning a legitimate domain name for the purpose of internal use with making the DNS records from that domain's zone public. One does not imply the other.

Buy the domain, know you will never conflict with something, and you're done (bar renewal!).

It's quite amusing you are promoting the use made up TLD names for internal use but previously you were deriding others for doing the same with 1/8 IP space(pre-2010) for the exact same internal only isolated use case.

I'm trying to picture a co-worker telling the team they went ahead and put all the management interfaces in the .burrito domain in order to save the company $10 in domain registrar fees.

Especially in that disaster-recovery scenario, when you're figuring out how to combine the different namespaces that different disconnected fragments of the internet are using, you really don't want namespace collisions.

Namespaces are abstract things that exist outside of the realm of actual network connectivity, and enable you to plan for all kinds of hypotheticals.