For about ten years, if your company ran its internal network on .corp, you were squatting. Not in the moral sense — Active Directory shops did it by the thousands and the tooling barely blinked. In the literal sense: .corp was an unclaimed top-level domain that ICANN could, in principle, have delegated to whoever paid for it. And for a stretch of 2012–2013, people were lining up to do exactly that.
That’s the setup for one of the quietly scariest problems in DNS, and the reason ICANN spent a decade getting to a fix that arrived, finally, in July 2024. The fix is .internal. It’s a good thing. It also solves only half of what people think it solves, and the half it leaves on the table is the half that actually bites you.
The collision nobody could see coming
Here’s the trap. Your laptop wants to reach fileserver.corp. Your local resolver knows about .corp because your admin configured it, so it answers from the internal zone and you get your files. Fine. But that only works as long as .corp doesn’t exist in the real, public root. The moment somebody buys .corp as a real gTLD and it gets delegated, every one of those internal queries that ever leaks past your resolver — a laptop on hotel wifi, a misconfigured VPN, a container with the wrong search domain — resolves to a stranger’s server. A server that just learned the internal hostname of your file share, and can answer for it.
In 2013 ICANN had Interisle Consulting measure how bad this actually was. The report, published that August, counted the leaked queries hitting the root servers for strings people assumed were private, and the numbers were enormous. .home and .corp were among the most-queried non-existent TLDs in the entire root — billions of queries a day for names that were never supposed to leave a building.
ICANN’s response was the Name Collision Occurrence Management Framework, and the piece of it you may have actually met in the wild is 127.0.53.53. When a genuinely new gTLD got delegated, the registry pointed the whole zone at that loopback address for 90 days — a deliberate, visible breakage so anyone with a leaking internal name would notice before a real server showed up to answer. The 53.53 is a mnemonic: port 53, twice, so you’d know it was a DNS collision and not a random outage. A clever hack for a problem that shouldn’t have needed one.
.corp, .home, and .mail were a worse category. They weren’t delegated with a warning period; they were flagged high-risk and deferred, and there were real applicants holding real receipts — $185,000 an application. It took until February 2018 for ICANN to formally give up, refund the fees, and admit the obvious: these strings were too embedded in private networks to ever be safe in the public root.
That’s the part that’s easy to miss. The reason we couldn’t have .corp as a real TLD is that too many people were already using it as if it were private. The squatting won. It broke the namespace for everyone else.
What .internal actually is
So the sensible move — the one the security community had been asking for through the SSAC’s SAC113 advisory — was to stop treating “which string is safe to squat on” as a guessing game and just designate one. Pick a label, promise on the record that it will never be delegated in the root, and tell everyone: build on this, and you’ll never collide with a real registration, because there will never be one.
On July 29, 2024, the ICANN Board did it. .internal is now reserved for private use and will never appear in the root zone. It’s the DNS version of what RFC 1918 did for IP addresses back in 1996 — carving out 10.0.0.0/8 and 192.168.0.0/16 so every home router and corporate LAN could reuse the same private space without anyone coordinating. Now you get the same guarantee for names. printer.internal, git.internal, k8s.internal — pick whatever you like, it’s yours, and it’s everyone else’s too, and that’s fine, because none of it is ever routable on the public internet.
If you’re standing up a new internal zone in 2026, this is the answer. Not .corp (dead), not .local (that’s mDNS, RFC 6762 — don’t overload it), not some real domain you own and quietly resolve differently on the inside. .internal. Done.
The half it doesn’t fix
Here’s where I have to be the person who ruins the party.
.internal is a reservation, not a special-use domain name. That distinction sounds like ICANN paperwork and it is, but it has a consequence you’ll feel. .local and .home.arpa are registered under RFC 6761, which means resolvers are supposed to know about them — a compliant stub resolver is told, in a standards document, not to send .local queries out to the public DNS. .internal has none of that. No RFC 6761 registration, no defined resolution behavior, nothing anywhere that tells a resolver to treat .internal as special. The only thing that exists is ICANN’s promise never to delegate it.
Read that again, because it’s the whole point. The reservation kills the collision risk — a stranger can never own .internal and impersonate your file server. It does nothing about the leak. Your resolver has no built-in reason to keep foo.internal inside your network. If a query leaks — same hotel wifi, same misconfigured container — it goes straight up to the public recursive resolvers and the root, exactly as before, exposing your internal hostnames to every operator on the path. The difference now is that nobody’s server answers, so nobody can hijack it. But the hostname still walked out the door.
So .internal traded a scary problem, impersonation, for a boring one, information leakage — and boring problems are the ones nobody gets around to fixing. You still have to configure your own resolvers to answer .internal authoritatively and, ideally, to refuse to forward it upstream. That’s on you, not on the reservation. ICANN gave you a safe name; it didn’t give you a mechanism.
One more thing that catches people: .internal names are, by definition, not globally unique. Every network on earth can have its own git.internal. So no public Certificate Authority will ever issue a TLS certificate for one — a globally-trusted cert for a name a million networks share would be a perfect impersonation tool, which is why the CA/Browser Forum banned publicly-trusted certs for non-unique names years ago and browsers reject the whole class. Want HTTPS inside your .internal zone — and you do — you’re running your own internal CA and pushing its root to your machines. That was true for .corp too. .internal doesn’t change it. It just makes official that you’ll be doing it forever.
Worth it anyway
None of this is a reason to skip .internal. Use it. It’s the first honest answer to a question — “what do I name my internal stuff?” — that the internet has been ducking since Active Directory shipped. A decade of 127.0.53.53, deferred gTLDs, and refunded application fees got us to a single reserved label, and that’s the right outcome.
Just don’t read the headline and think the work is done. ICANN reserved a name. Keeping your internal queries inside is still a config file with your name on it. The namespace is safe now. The plumbing is still yours.