Your internal domain and the 2026 gTLD round: what to check

If an applied-for string in the 2026 new gTLD round matches the suffix your internal domain uses, and ICANN does not rule it high-risk, that string goes into the public root zone on a temporary delegation of 90 to 365 days on ICANN-run name servers, comes out again, and, if the application reaches a contract, goes back in as a real registry delegation. The temporary delegation may give you no 127.0.53.53 warning at all.

ICANN published the applied-for list on Reveal Day, 7 October 2026: 1,615 applications in its snapshot. Three strings that private networks commonly use as suffixes are on it: .lan, the default local domain on OpenWrt-based routers, and .corp and .mail, two of the three strings the 2012 round classed as high-risk and never delegated. .home was not applied for. The procedures that decide what happens next are public, and so is the data from ICANN's Name Collision Analysis Project (NCAP) on how the 2012 round went for the networks on the receiving end. Read together from the operator's side, they say the usual safeguards are weaker than the usual advice assumes.

What happens to an applied-for string before it is delegated

The 2026 round replaced the 2012-era collision handling with a Name Collision Risk Management Framework, built on NCAP Study Two and finalized in four procedure documents published in January 2026. For an operator, the sequence that matters is this:

Dates in the first three rows come from ICANN's milestone announcement. The rest comes from the Initial Assessment procedure, the Temporary Delegation procedure, and section 7.7 of the 2026 Applicant Guidebook.

Temporary delegations do not all happen at once. The procedure caps root zone growth at "approximately five percent per month", and the Guidebook translates that into "roughly 75 Temporary Delegations per month initially". With 1,437 TLDs in the root today, 1,615 applications (some of them competing for the same string) cannot all be delegated in one month. Your string's date depends on its application's priority number and on when its Initial Assessment finishes, and ICANN has not published a schedule for either.

Removal is literal. Once the Technical Review Team (TRT) closes the data collection phase, "the root zone will no longer have the applied-for string delegated." Your leaked queries go back to NXDOMAIN. Months later, if the application is contracted, the string comes back for good under a registry that can sell second-level names in it.

Four data collection modes, and the one you cannot see

During temporary delegation ICANN's provider answers queries for the string in one of four modes defined in NCAP Study Two's Appendix 2. The Temporary Delegation procedure says the TRT "will use its professional judgment and experience to determine which collection methods, and in which order, will be used", and "may change data collection mode throughout the course of Temporary Delegation."

• No Interruption (NI): every query gets an empty NOERROR answer (NODATA) instead of NXDOMAIN.
• Controlled Interruption (CI): every name resolves to 127.0.53.53, with MX, SRV and TXT records pointing a human at ICANN. This is the 2012-round mechanism most admins have heard of.
• Visible Interruption (VI): names resolve to a sinkhole address, and its reverse DNS points at there-is-a-problem-with-your-dns.please-visit.name-collisions.icann.org.
• Visible Interruption and Notification (VIN): VI plus a web server on the sinkhole that explains the collision.

Here is the NI zone exactly as NCAP's Appendix 2 specifies it, with @ replaced by the delegated string:

$TTL 60
$ORIGIN @
@ IN SOA ns1.trial-delegation.icann.org. (
      name-collision-admin.icann.org.
      1     ; Serial
      3600  ; Refresh
      3600  ; Retry
      86400 ; Expire
      60 )  ; Negative Cache TTL
  IN NS ns1.trial-delegation.icann.org.
  IN NS ns2.trial-delegation.icann.org.
* IN HINFO "" ""

A wildcard HINFO record means every name under the string exists, but no query type other than HINFO has data. NCAP is explicit about why ICANN wants this: "applications that originate such queries are not expected to behave differently with the NODATA response; thus, no disruption is anticipated." And: "With NODATA responses, resolvers are forced to use the full query name in a DNS query, where it might not otherwise be included, due to negative caching and QNAME minimization." (NCAP Study Two report, section 3.5.1.)

Read those two sentences from the collided network's side. Nothing breaks, so nobody opens a ticket. QNAME minimization stops helping, so the full names your clients leak, fileserver.lan, _ldap._tcp.dc._msdcs.lan, reach ICANN's temporary servers and get analyzed. NI is the right mode for ICANN's data and the worst mode for your awareness. You get no signal in exchange for your hostnames.

The NXDOMAIN to NODATA flip also does less to resolution than you might fear, at least on Linux. glibc's __res_context_search keeps walking the search list on both:

switch (statp->res_h_errno) {
case NO_DATA:
	got_nodata++;
	[[fallthrough]];
case HOST_NOT_FOUND:
	/* keep trying */
	break;

So with glibc, NI does not change which names get tried; it can change the reported error (NO_DATA instead of HOST_NOT_FOUND when a search step got NODATA) and what your resolver logs and caches. Windows and macOS ship their own stub resolvers, so do not assume glibc's behavior carries over. You can test before any real delegation: serve the NI zone above for a made-up string from a lab resolver, point a client at it, and compare its lookups of short names against the same client on NXDOMAIN.

Controlled interruption is IPv4 only in 2026

Even if the TRT picks CI for your string, the CI zone contains A records only. ICANN looked at an IPv6 equivalent and, per its March 2026 public comment summary, "decided to not perform controlled interruption with IPv6 in the 2026 Round." An IPv6-only client asking for AAAA gets NODATA under CI too. The warning signal has a hole exactly where newer networks live.

Why ICANN will not block your suffix for you

In the 2012 round, out of roughly 1,400 unique strings, only three were assessed as high-risk: .corp, .home and .mail (Applicant Guidebook section 7.7.1). The 2026 bar is written down in the high-risk string classification model, and it is high: a string is high-risk only with "visible evidence that name collisions are likely to occur with severe, widespread and sustained impacts", where "likely" means "a subjective probability of at least 66%".

The model's examples of qualifying impact are "hundreds of thousands of home routers" failing, or "a vast number of e-mail systems all around the globe" rerouting internal mail. It also says that "much of the responsibility to address an affected information system's shortcomings rests with the owner, provider or manufacturer of this system."

That is a defensible position for a root zone operator, and it means your company's private suffix, used by your company only, is not the case the framework is built to protect. If your suffix collides, plan on fixing it yourself.

Two of the 2012 high-risk strings are back: .corp and .mail were both applied for in 2026. At the time of writing ICANN's application portal shows both in pre-evaluation with no high-risk label; the name collision assessment that decides it has not run yet.

The two standard safeguards failed most of the time last round

The usual advice is to watch your logs for 127.0.53.53 and to make sure your internal resolvers answer authoritatively for your suffix. NCAP's root cause analysis of the 2012 round (Appendix 4b of the Study Two report) tested both against what affected organizations reported.

127.0.53.53 mostly went unseen

Of the survey respondents who used a DNS suffix that later became a TLD, 7 of 10 had technical problems after delegation. Three of those seven noticed within days, three only within months. Among the seven, one saw 127.0.53.53 and it helped, one saw it but did not understand it, and in "the five (71%) remaining cases, 127.0.53.53 was not observed at all." NCAP's summary line: controlled interruption "is effective at disruption but not at root cause identification."

Seven respondents is a tiny sample; NCAP itself notes that "with the limited responses we received, it is hard to generalize impact." It is still the only measured data on the question, it comes from ICANN's own study, and it points the same way as everything else in the appendix. Treat 127.0.53.53 as a bonus signal. Detection has to come from your own query logs.

Authoritative internal resolvers did not stop leaks

NCAP's finding is titled "Configuring DNS resolvers as authoritative for DNS suffixes is not a panacea." The survey showed every combination of resolver configuration and outcome, including organizations whose resolvers were authoritative and still had problems. Of the 24 collision reports ICANN received from organizations, 8 (33%) mentioned remote users or VPN, and 8 (33%) mentioned Active Directory.

The mechanism is ordinary. A laptop uses the corporate resolver only while the VPN is up. Before it connects, at a hotel or at home, it uses whatever resolver the local network hands out, and every lookup for an internal name goes to the public DNS. Your authoritative zone never sees those queries. The temporary delegation's servers do.

What to check after Reveal Day

None of this needs the final list to start, but the comparison step does. Here is the order that makes sense:

1. Inventory every suffix your clients use. Not only the zone apexes on your DNS servers: Active Directory domain names, DHCP-pushed search domains (options 15 and 119), VPN-pushed DNS suffixes, search lines in /etc/resolv.conf, and suffixes baked into configs and certificates. On clients, resolvectl status (systemd-resolved), scutil --dns (macOS) and ipconfig /all (Windows, "DNS Suffix Search List") show what is actually in effect.
2. Take the rightmost label of each suffix and compare it to the applied-for list. Do it on Reveal Day, again after the Replacement Period closes on 21 October, and again against the final list on String Confirmation Day, 17 November.
3. Check delegation status straight from a root server. Today a reserved or unapplied string returns NXDOMAIN; a delegated one returns a referral. Re-run this during the round to see when a temporary delegation starts and ends.
4. Test what leaks. From a laptop off the VPN, look up a name under your suffix through a public resolver. Before delegation you get NXDOMAIN. Under NI you get NOERROR with zero answers and an SOA from the temporary provider; under CI, 127.0.53.53.
5. Log for the change, not only the address. Alert on any NOERROR answer for your private suffix coming from outside your own servers, plus 127.0.53.53 in application and resolver logs. The NCAP appendix shows the address alone is not enough.
6. Report it. ICANN's name collision page has a report form, and the Temporary Delegation procedure says the TRT "will also monitor submitted community reports of name collisions" during the data collection phase. A report during temporary delegation is the one input you have into whether the string gets classified as high-risk.

The root server check from step 3, run at the time of writing for the reserved string internal and for dev:

$ dig +norecurse @a.root-servers.net internal. NS +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12275
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig +norecurse @a.root-servers.net dev. NS +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27588
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 11

NXDOMAIN with aa means the root says the string does not exist. NOERROR with five authority records and no aa is a referral to the TLD's servers. When your suffix flips from the first shape to the second, it is delegated, temporarily or not.

One caching detail matters at that flip. The root zone's SOA carries a negative TTL of 86400 seconds, so a resolver that cached NXDOMAIN for your suffix (or cached the root's NSEC range covering it) can keep returning NXDOMAIN for up to a day after the delegation appears. The NI and CI zones use a 60-second negative TTL, so removal shows up fast. The same negative caching is behind most of what people call DNS propagation delays.

For the search-list side of the problem specifically, ICANN's 2014 Guide to Name Collision Identification and Mitigation for IT Professionals still holds up. Section 5 walks through inventorying systems that use short unqualified names, moving them to fully qualified names, and turning off search lists at shared resolvers.

Where to move your internal domain: a subdomain you own beats .internal

If a suffix collides, or you are tired of wondering, there are two real choices: .internal or a subdomain of a public domain you already own, such as corp.example.com. For most organizations the owned subdomain is the better answer.

.internal is safe from this round. ICANN Board resolution 2024.07.29.06 "reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications." The standards side is thinner than the reservation suggests. The IETF document, draft-davies-internal-tld-06 (6 May 2026), is an Informational Internet-Draft on the Independent Submission stream, not an RFC. Its own limitations section lists the problems:

• Not globally unique: "multiple networks may use the same name, such as 'accounting.internal,' for entirely different purposes." Merge two companies and you have a collision of your own making.
• DNSSEC: "DNSSEC-validating resolvers that rely on the global DNS trust anchor will fail to resolve names ending in 'internal.'"
• Cookies: a cookie set for accounting.internal on one network may be sent to a different accounting.internal on another.
• Certificates: public CAs "are not expected to issue certificates for it," so you run a private CA.

The DNSSEC point is easy to see from a validating public resolver. The root proves the name does not exist, and the answer is signed:

$ dig @1.1.1.1 +dnssec printer.internal A +noall +comments +authority
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6833
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
int.        86400 IN NSEC international. NS DS RRSIG NSEC
.           86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY TYPE63

The ad flag and the int. NSEC international. record mean "nothing exists between int and international", authenticated. A validating resolver that forwards .internal to your own servers will see your unsigned answers contradict that proof unless you exempt the zone (for example Unbound's domain-insecure or BIND's validate-except). Forget the exemption on one resolver and you get SERVFAIL, the failure mode covered in diagnosing DNSSEC validation failures. Home networks have a cleaner option here: home.arpa (RFC 8375) was given an insecure delegation precisely so validators do not trip on it.

A subdomain of a domain you own has none of these problems: it is globally unique, it validates normally, and a public CA can issue certificates for it. It does have one cost that is easy to miss. Your whole internal namespace now depends on that public domain staying registered and its delegation staying correct. An expired registration or a broken NS change stops being a website problem and becomes an "every internal hostname" problem.

Concretely: put the parent domain on a registrar lock and auto-renew, watch its expiry date (domain expiry monitoring covers the lifecycle), and watch its NS and DS records at the registry as well as at your provider. Domain monitoring vs DNS monitoring explains why those are two separate checks.

Whatever you choose, the real deadline is the day your colliding string enters temporary delegation, which ICANN will schedule by priority number and may run in a mode designed so that you do not notice. Do the inventory before then.