Skip to content
RU

ERR_ICANN_NAME_COLLISION

Key idea:

ERR_ICANN_NAME_COLLISION — ICANN-level warning. Your internal network uses a domain (.corp, .home, .lan) that became a public TLD after ICANN gTLD expansion (2013+). Now external DNS resolves your internal hostname → confusion. Chrome warns. Fix: rename internal zones to .internal or .arpa (reserved), or explicitly blacklist.

Below: causes, fixes, FAQ.

Check your domain's DNS →

Common Causes

  • Internal AD domain like .corp became a public gTLD
  • Old split-horizon DNS setup with .home, .lan
  • /etc/hosts entries with common names
  • Resolver tried public DNS before internal
  • NetBIOS broadcast names

Step-by-Step Fix

  1. Rename internal zone to .internal, .home.arpa (RFC 8375)
  2. Strict DNS suffix order: internal first
  3. Or forbid resolver for public TLDs on endpoints
  4. AD migration — a big project (prepare)
  5. Temporary: /etc/hosts manual entries for critical hosts

Check DNS records →

Related SSL Errors

TL;DR: Understanding ERR_ICANN_NAME_COLLISION

The ERR_ICANN_NAME_COLLISION error occurs when a domain name resolves to an internal TLD (Top-Level Domain) that collides with a public TLD, causing DNS resolution failures. This typically affects private networks or local test environments where domains are misconfigured or overlap with existing ICANN TLDs. To resolve this, ensure your internal TLDs do not conflict with public TLDs by using custom or non-ICANN TLDs.

What Causes ERR_ICANN_NAME_COLLISION?

The ERR_ICANN_NAME_COLLISION error arises when a domain name used in a private network conflicts with a public TLD registered with ICANN (Internet Corporation for Assigned Names and Numbers). This conflict can occur when:

  • Using a non-standard TLD in a local environment that is also a valid public TLD, such as .local, .test, or .home.
  • Misconfiguration in DNS settings, causing the internal network to resolve the domain to the public TLD.
  • A domain name that is not properly segmented between internal and external usage.

Such collisions can lead to issues in DNS resolution, affecting the accessibility of services hosted on the conflicting domain.

Resolving ERR_ICANN_NAME_COLLISION: Practical Solutions

To resolve the ERR_ICANN_NAME_COLLISION error, it is essential to implement best practices in domain naming and DNS configuration. Below are several strategies you can employ:

  1. Use Custom TLDs: Instead of using standard TLDs, opt for custom TLDs that are not registered with ICANN. For example, instead of using .local, consider using .testlocal or .example.
  2. DNS Configuration: Ensure your DNS settings do not point to conflicting public TLDs. You can use the following command to check your current DNS settings:
nslookup yourdomain.test

Replace yourdomain.test with your actual domain. If this resolves to a public IP, you may need to adjust your DNS records.

  1. Modify Hosts File: For local testing, you can add entries to your hosts file to avoid DNS resolution issues. On Windows, edit C:\Windows\System32\drivers\etc\hosts, and on Linux or macOS, edit /etc/hosts. Add lines like:
127.0.0.1 yourdomain.test

This will force the system to resolve yourdomain.test to your local machine.

  1. Network Segmentation: If your organization has multiple environments (development, testing, production), ensure that they are properly segmented and that domain names are unique across these environments to prevent collisions.

By implementing these practices, you can minimize the risk of encountering the ERR_ICANN_NAME_COLLISION error and ensure smooth operation of your web services.

A / AAAAIPv4 and IPv6 host addresses
MX RecordsDomain mail servers
TXT / SPFVerification & anti-spoofing
NS / SOAName servers & zone authority

Why teams trust us

12
DNS record types
SPF+DKIM
email protection
<1s
DNS response
3
check regions

How it works

1

Enter domain

2

Select record type

3

Get DNS response

What are DNS Records?

DNS (Domain Name System) translates domain names into IP addresses. DNS records are instructions that define where to route traffic, email, and how to verify domainownership.

Complete Lookup

Query all record types — A, AAAA, MX, NS, TXT, CNAME, SOA — in a single request.

Instant Results

Direct queries to authoritative servers. Results in milliseconds, no caching.

Security Checks

SPF, DKIM, and DMARC analysis to evaluate email protection against spoofing and phishing.

Export & History

Save check results. Compare DNS records before and after registrar changes.

Who uses this

DevOps

DNS check after deploy

Email marketers

SPF/DKIM/DMARC audit

SEO

DNS config audit

Sysadmins

DNS zone control

Common Mistakes

Missing SPF recordWithout SPF, emails may land in spam. Add a v=spf1 TXT record.
Single NS serverIf the only NS fails, the domain becomes unreachable. Use at least 2 NS servers.
CNAME conflicting with other recordsCNAME cannot coexist with MX or TXT on the same name — this violates RFC.
TTL set too highWith 86400s TTL, DNS changes take a full day. Lower TTL to 300 before migrations.
Missing PTR recordMail servers check PTR. Without it, emails may be rejected.

Best Practices

Set up SPF + DKIM + DMARCThe trio of records that protects your email from spoofing and improves deliverability.
Use 2+ NS serversDistribute NS servers across different networks for redundancy.
Lower TTL before migrationSet TTL to 300 at least 24-48 hours before an IP change for fast propagation.
Verify DNS after changesAfter updating records, confirm changes propagated correctly and no errors remain.
Add a CAA recordCAA restricts which Certificate Authorities can issue SSL certificates for your domain.

Get more with a free account

DNS check history, API keys and DNS change monitoring.

Sign up free

Learn more

Frequently Asked Questions

Which TLDs currently "collide"?

.corp, .home, .mail, .office — NOT in public use but reserved by ICANN. Safer: .internal (proposed reserved), .home.arpa, .localhost.

Is this a security risk?

Yes: attacker can register a .corp domain, resolve internal names to malicious IPs, MITM.

Does Chrome specifically block?

Chrome warns, does not block. But may treat as suspicious for certain workflows.

Reserved TLDs 2026?

.internal (IETF draft), .test, .localhost, .invalid, .example — safe. Anything else — ideally check the public registry.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.