Skip to content

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 site's SSL →

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 SSL Certificate →

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.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

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.