Understanding and Preventing Namespace Collisions

Published: September 2025. Updated: August 2026. Reviewed by Encryption Consulting’s PKI Services team.

On August 12, 2026, ICANN closed the application window for its second round of new generic top-level domains, the first expansion of the public DNS namespace since 2012. Every one of those applications is a candidate string that could, in theory, match a name your organization is already using internally. That is the entire namespace collision problem in one sentence: a private naming decision made years ago running into a public naming decision made today. In software development, networking, and domain management, few issues are this well documented and this widely ignored. This guide explains what a namespace collision actually is, why it matters, how to select the right reserved namespace, what the threat model looks like, and how to remediate a collision you already have.

What Is a Namespace Collision?

A namespace collision occurs when a name used inside a private network, such as a hostname, an Active Directory forest name, or a certificate subject, matches a name that is later delegated on the public DNS. Once that public delegation happens, a query that used to resolve internally can resolve externally instead, without any change to the requesting device’s configuration.

Here is the mechanism in practice. Suppose your organization runs an internal domain called mysite.express, with a test server reachable at test.mysite.express and a web server named www. For years, pinging www.test from inside the network resolves correctly through your internal DNS search suffix. Then ICANN delegates .express as a public TLD. Now, depending on search-order and split-horizon configuration, a query for www.test can be interpreted as a request for the public domain test.express rather than your internal host, and the client is silently routed to whatever the public registrant of that domain has set up. The internal name still works if you use the fully qualified form, www.test.mysite.express, but any system relying on the short name is now exposed to ambiguity that did not exist the day before.

The term covers more than DNS hostnames. Active Directory realm names, LDAP distinguished names, internal certificate subjects, and even internal API namespaces can all collide with a newly delegated public string using the same underlying mechanism: a private name that was never registered anywhere authoritative colliding with a name that eventually is.

Why Do Namespace Collisions Happen?

Namespace collisions exist because organizations chose internal names before those strings had any formal reservation, and ICANN’s new gTLD program keeps expanding the pool of strings that can later become real, public domains.

Two trends run in opposite directions and meet at the collision point:

• Ad hoc internal naming. For decades, IT teams picked internal TLD-style suffixes such as .corp, .home, .mail, .lan, and .local with no registry behind them, because nothing stopped them. ICANN’s Security and Stability Advisory Committee documented this widespread practice, along with the resulting leakage of internal queries onto the public DNS, in its SAC113 advisory on private-use TLDs.
• Expanding public namespace. ICANN’s new gTLD program has delegated over 1,200 new strings since the first 2012 round, and its 2026 application round accepted submissions from April 30 through August 12, 2026, for a further wave of delegations. Each new string is a candidate collision with whatever an organization already uses internally, and it goes both ways: businesses want more naming choice, cheaper registration, and less congestion on crowded strings like .com, while every new delegation risks matching a name someone already relies on privately.

Namespace collision is not a hypothetical. It is a structural consequence of running a two-tier naming system, private and public, without a shared reservation authority for the private tier until very recently.

How Does ICANN’s Name Collision Framework Manage the Risk?

ICANN manages new-gTLD collision risk with a pre-delegation “Controlled Interruption” period that deliberately breaks unresolved queries for 90 days so administrators notice and fix the problem before the TLD is live for everyone else.

The Name Collision Occurrence Management Framework, approved in 2014, works like this:

1. Before a new gTLD is delegated, the registry is required to point every unresolved query under that TLD to a single, non-routable address: 127.0.53.53.
2. Any system administrator who sees traffic hitting that specific address has a clear, documented signal that one of their internal systems is querying a name that is about to become public.
3. The administrator has a window, typically 90 days, to reconfigure the affected system before the TLD resolves normally for the rest of the internet.

This process only works if someone is actually watching for connections to 127.0.53.53. Organizations that never look at their DNS logs during a Controlled Interruption window get no benefit from the framework at all, which is why monitoring is a prevention control in its own right, not an optional extra.

What Is the Threat Model for a Namespace Collision?

The threat model for a namespace collision assumes an attacker who registers the exact public domain that matches your internal naming pattern, then waits for misrouted internal traffic to arrive at infrastructure they control.

Concretely, the attack chain looks like this:

• Reconnaissance. The attacker identifies a likely internal naming pattern, either from a data leak, a job posting, a certificate transparency log entry from before the 2015 cutoff, or simple guessing based on common internal TLDs like .corp or .internal.
• Registration. Once a matching TLD is delegated, the attacker registers the exact second-level domain the target’s internal systems already query, for example mail.corp if that string becomes resolvable.
• Interception. Misconfigured clients, VPN split-tunnel setups, or roaming laptops outside the corporate network send internal-looking queries to the public internet, where they now resolve to the attacker’s servers instead of failing or reaching the real internal host.
• Exploitation. The attacker can run a man-in-the-middle proxy that harvests credentials, serve a phishing page that mimics an internal login portal, or simply log whatever internal data leaks in the queries themselves, such as authentication attempts, internal hostnames, or API tokens.

The certificate dimension makes this worse. Before November 2015, an organization could obtain a publicly trusted TLS certificate for an internal name like mail.corp because certificate authorities had no requirement to verify that the name resolved consistently for everyone. If that certificate is still trusted anywhere, and the corresponding public domain is later registered by an attacker, the attacker can present a certificate chain that a browser will trust, because it was issued by a legitimate public CA before the ban took effect. This specific risk is exactly why the CA/Browser Forum acted.

How Do Namespace Collisions Intersect With Certificate Issuance?

Namespace collisions are the direct reason publicly trusted certificate authorities can no longer issue certificates for internal server names or reserved IP addresses.

The CA/Browser Forum’s Baseline Requirements, first adopted in 2011 and phased in from July 1, 2012, set a hard deadline: no publicly trusted certificate authority could issue a certificate containing an internal server name or a reserved IP address (RFC 1918 or RFC 4193 ranges) with an expiration date after November 1, 2015. Any certificate matching those criteria had to be revoked by October 2016. The reasoning is the same collision logic described above: an internal name cannot be externally verified as belonging to any specific organization, and if that name is ever delegated on the public DNS, the certificate becomes a liability instead of a trust anchor.

This is where namespace selection and certificate policy have to work together. An organization that still issues internal certificates with names like server.corp, even from an internal private CA rather than a public one, is building the exact naming pattern that a future public delegation, or an attacker anticipating one, can exploit. The fix is not just picking a safe internal namespace; it is making sure every certificate template, enrollment policy, and certificate practice statement (CP/CPS) enforces that namespace consistently across every issuing CA in the environment.

Which Reserved Namespace Should You Use?

Use .internal for new private-network deployments, since it is the only TLD-style string ICANN has permanently reserved specifically so it can never be delegated on the public DNS.

The table below compares the realistic options for internal naming as of August 2026:

Namespace option	Collision risk	Standardization status	Best use case
.internal	None; permanently reserved	Reserved by ICANN Board resolution, July 29, 2024, following SSAC recommendation SAC113	New private networks, hybrid cloud, container platforms
.corp, .home, .mail, .lan (ad hoc)	High; multiple were formally requested as public gTLDs	Never registered anywhere; informal convention only	Legacy environments pending migration; not recommended for new builds
.test, .example, .invalid	None for their intended purpose	Reserved by IETF, RFC 2606 and RFC 6761	Documentation, sample configuration, non-production test environments
.local	None for its intended purpose, high if repurposed	Reserved for multicast DNS (mDNS) by RFC 6762	Zero-configuration device discovery only, never general enterprise DNS
Fully registered public domain, dedicated internal zone (e.g., internal.yourcompany.com)	None; you control the parent zone	Standard delegated DNS, no special reservation needed	Enterprises that already own a stable public domain and want internal zones under it

Most enterprises land on one of two answers: adopt .internal for greenfield builds, or delegate a private subdomain of a public domain they already own and control, such as internal.yourcompany.com, since both approaches guarantee the namespace can never be claimed out from under them.

What Are the Performance and Interoperability Trade-offs?

Reserved-namespace adoption trades a real but manageable migration and compatibility cost for the elimination of collision risk, and the size of that cost depends heavily on how long the legacy naming has been in place.

• Split-horizon DNS overhead. Running separate internal and external views of the same zone, or maintaining a dedicated internal zone alongside a public one, adds operational complexity: two sets of records to keep synchronized, and two failure modes to monitor instead of one.
• Operating system and application support lag. Because .internal was only reserved in mid-2024, some older operating systems, network appliances, and third-party software still hardcode assumptions about legacy suffixes like .local or treat unrecognized TLDs inconsistently. Expect a multi-year tail before every device on a large estate treats .internal the same way.
• DNSSEC validation latency. Adding DNSSEC to internal zones authenticates responses and blocks cache-poisoning attempts that could otherwise exploit a collision, but it adds cryptographic validation overhead to every lookup and requires key-rollover operations that many internal DNS teams have never had to run before.
• Migration cost versus risk reduction. Renaming an Active Directory forest or re-issuing every certificate that references an old internal suffix is disruptive and expensive. It is still cheaper than an incident caused by a collision, but it is a real project with real downtime risk, not a configuration toggle.

How Do You Remediate an Existing Namespace Collision?

Remediating a namespace collision means auditing every internal name in use, confirming which ones are at risk, and migrating the risky ones to a reserved namespace on a controlled schedule rather than waiting for an incident to force the timeline.

1. Inventory every internal namespace in use. Pull DNS zone files, Active Directory forest and domain names, internal certificate subjects, and any hardcoded internal hostnames from configuration management databases and infrastructure-as-code repositories.
2. Flag ad hoc TLDs. Cross-reference every internal suffix against ICANN’s current and pending delegated gTLD list, prioritizing anything using .corp, .home, .mail, .lan, or any string that appeared in a recent new gTLD application round.
3. Audit certificates against the internal-names ban. Search certificate transparency logs and your internal CA database for any certificate, public or private, that still references an internal name in its subject or SAN fields, and confirm none were issued by a public CA after the November 2015 cutoff.
4. Select the target namespace. Use the decision table above to choose between .internal and a dedicated subdomain of a domain your organization already owns.
5. Migrate in phases, starting with monitoring. Enable DNS query logging before changing anything, watch for queries hitting ICANN’s Controlled Interruption address (127.0.53.53) during any active TLD rollout, and use that data to find systems you missed in the inventory step.
6. Cut over and decommission. Reconfigure DNS clients, reissue certificates under the new namespace, and retire the old zone only after a monitoring period confirms nothing is still querying it.
7. Re-audit after every new gTLD round. Repeat the flagging step whenever ICANN opens a new application window, since the 2026 round alone could add a large batch of new public strings your organization has never checked against.

Deployment Examples: How Cloud Platforms Handle This

Every major cloud provider now offers a private DNS mechanism specifically designed to keep internal names isolated from the public namespace, and using it correctly is most of the prevention work for cloud workloads.

• Azure Private DNS Zones. Organizations link a private zone to one or more virtual networks so that names such as hr.internal.example resolve only inside those networks, never on the public internet, which keeps a namespace like .internal or a reserved subdomain fully isolated even in hybrid deployments that also use public Azure services.
• AWS Route 53 private hosted zones. A private hosted zone associated with one or more VPCs answers DNS queries for an internal namespace without that zone ever being reachable from outside AWS, giving teams the same collision-proof isolation for workloads running in EC2, ECS, or EKS.
• Google Cloud DNS private zones. Google Cloud’s private zones scope resolution to specified VPC networks, and Google explicitly recommends customers plan around upcoming gTLD delegations rather than assuming an ad hoc internal suffix will stay safe indefinitely.
• Kubernetes cluster-internal DNS. Cluster DNS addons resolve service names within a cluster-local domain, typically cluster.local by default; teams that rename this to a namespace under .internal or a dedicated owned subdomain remove one more ad hoc string from their collision exposure.

What Are the Key-Management Dependencies for Certificate-Based Mitigation?

Any organization that issues its own certificates for an internal namespace, rather than relying purely on DNS-layer controls, takes on the key-management responsibilities of running a private certificate authority, and those responsibilities do not disappear just because the certificates never touch the public internet.

• Root and intermediate CA key protection. The private key that signs every internal certificate is the single point of failure for the entire internal trust chain; it belongs in a FIPS 140-validated hardware security module, not on a general-purpose server’s file system.
• Certificate template and naming enforcement. Templates need to actively reject any request for a name in a deprecated ad hoc TLD, which requires policy enforcement at issuance time, not a naming convention documented in a wiki that nobody checks.
• Lifecycle visibility across every issuing CA. A single unmanaged internal CA that nobody remembers exists is exactly how organizations end up with expired, orphaned, or policy-violating certificates still trusted somewhere on the network.
• Revocation capability. If a namespace migration retires an old internal name, every certificate issued for it needs to be revocable on a working CRL or OCSP responder, not just left to expire quietly.

Limitations

No single control eliminates namespace collision risk completely. A few honest limits are worth stating up front:

• Reserving .internal protects new deployments, but it does not retroactively fix every device, appliance, or third-party application already hardcoded against a legacy suffix like .corp or .local; those still need individual remediation.
• ICANN’s Controlled Interruption process only catches collisions during the specific window around a new TLD’s delegation; a namespace that collides with a TLD delegated years earlier gets no benefit from monitoring a fresh rollout.
• The CA/Browser Forum’s ban on internal-name certificates applies to publicly trusted CAs. It does not stop an organization from continuing to issue internal-name certificates from its own private CA, which is why namespace discipline still matters even where public trust rules do not directly apply.
• Split-horizon DNS reduces collision exposure but adds its own operational risk: a misconfigured internal view can leak internal names into the public view, which is a different failure mode with a similar consequence.

What Would Encryption Consulting Recommend?

Start with an inventory, not a rename. Before anyone touches a DNS zone or a certificate template, we recommend a full internal-namespace and internal-certificate audit, because most organizations underestimate how many systems still depend on an ad hoc suffix that was never supposed to be permanent.

Our CertSecure Manager platform enforces namespace policy at the point of issuance rather than after the fact: certificate profiles can require verified, non-colliding domain names, block requests for deprecated internal-style TLDs, and give every issuing CA in a hybrid environment role-based access control so naming policy is consistent instead of tribal knowledge held by one administrator. A financial services client used CertSecure Manager to restrict certificate issuance to verified internal domains only, closing off a class of unauthorized-access risk that an unmanaged internal CA had left open for years.

For organizations planning a namespace migration, our Encryption Advisory Services team designs the certificate policy and practice statement that makes reserved-namespace adoption enforceable, and our HSM Services secure the root and intermediate keys that anchor every certificate your new namespace will rely on. If your organization is running any internal PKI at all, whether for internal websites, service-to-service authentication, or device identity, get in touch with our team before your next namespace decision, not after a collision forces one.

Frequently Asked Questions

Is a namespace collision the same thing as a domain collision?
The terms are used interchangeably in most contexts, including ICANN’s own documentation. “Domain collision” is sometimes used specifically for DNS name conflicts, while “namespace collision” is the broader term that also covers Active Directory realm names, certificate subjects, and other naming systems that can overlap with a newly delegated public string.

Can I still use .local for my internal network?
Only for its intended purpose. RFC 6762 reserves .local specifically for multicast DNS (mDNS), the zero-configuration discovery protocol used by devices on a local segment. Using .local as a general internal enterprise TLD, alongside Active Directory or other internal DNS, creates exactly the kind of ambiguity a reserved namespace is supposed to prevent.

Why can’t I get a public certificate for my internal server name anymore?
The CA/Browser Forum’s Baseline Requirements have prohibited publicly trusted certificate authorities from issuing certificates for internal server names or reserved IP addresses since November 2015, with any prior certificates required to be revoked by October 2016. Internal names cannot be externally verified as belonging to a specific organization, which is the same underlying risk that drives namespace collisions.

What is Controlled Interruption?
Controlled Interruption is the mechanism in ICANN’s Name Collision Occurrence Management Framework where a newly delegated gTLD registry routes all unresolved queries to the address 127.0.53.53 for a defined period, typically 90 days, so system administrators can spot and fix internal systems that were unknowingly depending on that string resolving as a private name.

How do I know if my organization is affected by ICANN’s 2026 gTLD round?
Compare your internal namespace inventory, DNS suffixes, Active Directory names, and internal certificate subjects, against the list of strings applied for in the round that closed August 12, 2026. ICANN publishes applied-for strings publicly once the application window closes, and any match is a candidate for migration before that TLD is delegated.

Conclusion

Namespace collision is a naming problem with security consequences, not a security problem on its own, and that distinction is exactly why it gets overlooked. An internal name chosen a decade ago with no thought for global uniqueness can quietly become an attacker’s opportunity the moment ICANN delegates the matching public string, and the 2026 new gTLD application round means that moment is arriving for a fresh batch of organizations. The fix does not require exotic tooling: inventory what you actually have, move to a namespace ICANN has permanently reserved or a domain you already control, keep certificate issuance policy aligned with the CA/Browser Forum’s internal-names ban, and monitor every new TLD rollout for signs that one of your systems was quietly depending on a string that was never really yours.

References

• ICANN, “Name Collision Occurrence Management Framework,” 2014: icann.org
• ICANN Security and Stability Advisory Committee, “SAC113: SSAC Advisory on Private-Use TLDs”: itp.cdn.icann.org
• ICANN, Approved Resolutions, Special Meeting of the ICANN Board, July 29, 2024 (reservation of .internal): icann.org
• ICANN New gTLD Program, “2026 Round General Information”: newgtldprogram.icann.org
• CA/Browser Forum, “Guidance on Internal Names”: cabforum.org
• IETF, RFC 6762, “Multicast DNS”: rfc-editor.org