What does the 127.0.53.53 address mean?

It's a deliberate signal, not a real server. When ICANN delegates a brand-new top-level domain, the framework it approved in 2014 makes the registry point the whole new zone at 127.0.53.53 for the first 90 days — a period called *controlled interruption*. The address was chosen to be noticed: it loops back to your own machine (127.x is localhost), so nothing actually connects, and the last two octets spell 53.53 as a mnemonic for DNS, which runs on port 53. The point is to make a name collision fail loudly and land in your logs instead of silently sending traffic somewhere it shouldn't go. Chrome recognizes that address specifically and, rather than trying to connect to your own loopback, shows ERR_ICANN_NAME_COLLISION to tell you what happened.

Is this a problem with the website or with my computer?

Almost always your side — or more precisely, your name resolution. The error means a name you typed resolved, on your machine, to 127.0.53.53. That happens for one of two reasons: the name belongs to a top-level domain that used to exist only inside private networks and has since become a real public gTLD (so the public DNS now answers for it), or your DNS *search domain* quietly appended a suffix to a short, unqualified name and turned it into one of those colliding names. The remote site isn't refusing you; the name is landing somewhere it was never meant to. Resolve the exact fully-qualified name from outside your network to see what the public DNS actually returns.

How do I stop it from happening?

Stop relying on a name that collides with the public DNS. If you're using a made-up internal TLD like .corp, .home, or .mail, or a bare single-label host that a search domain expands, move your internal names onto something reserved for the purpose: a real subdomain of a domain you own (internal.example.com), or the RFC 8375 name .home.arpa for home networks. If the collision is with a TLD that genuinely went public (.dev, .app, and others are real now), you must rename — you cannot win a fight with the global root. Fully qualify the name (add the trailing dot or the full domain) so your resolver stops appending a search suffix, and clear the Chrome and OS DNS caches after the change.

Views: 7

ERR_ICANN_NAME_COLLISION: Fix the Chrome DNS Error

ERR_ICANN_NAME_COLLISION means a name resolved to 127.0.53.53. Check the name, your search domain, and if the TLD is public. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome refuses to load the page with ERR_ICANN_NAME_COLLISION — “This site can’t be reached.” No timeout, no certificate warning, no server error. The name you typed didn’t fail to resolve; it resolved to the wrong thing on purpose, and Chrome caught it.

Symptoms

Chrome shows ERR_ICANN_NAME_COLLISION and the page never loads.
It hits a short internal name, a development hostname, or a name under a made-up TLD like .corp, .home, .mail, or .dev — not the wider web.
The same name may have worked for years and only recently broke.
ping or nslookup for the name shows the address 127.0.53.53.
It often started after joining a new network, changing DNS servers, or after a TLD you were using internally became a real public domain extension.

What This Error Actually Means

There is a category of name that lives only inside private networks: a company that calls its intranet http://wiki/, a setup that puts everything under .corp, a laptop configured with a DNS search domain so that typing printer really means printer.office.example. These names were never in the public DNS, so nobody outside the network could answer for them, and that was fine — until the public DNS grew a name that matches.

ICANN’s new-gTLD program added hundreds of top-level domains. Every time it delegates one, there’s a risk that the string collides with a name someone was already using privately. If your network resolves something.dev internally and .dev becomes a real, delegated public TLD (it did — it’s operated by Google and is HSTS-preloaded), your queries can suddenly reach the public DNS and get a real answer, or a stray answer, for a name you meant to keep inside.

To keep that from happening silently, ICANN’s Name Collision Occurrence Management Framework, approved in 2014, requires the operator of a newly delegated TLD to point the entire new zone at a single address — 127.0.53.53 — for a 90-day controlled interruption period. The address is a trap by design. 127.x.x.x is loopback, so a browser that follows it just talks to itself and nothing happens; and 53.53 is a mnemonic for DNS (port 53) so it stands out in a log. The whole point is to convert a quiet, dangerous misdirection into a loud, obvious failure. Chrome goes one step further: it recognizes 127.0.53.53 as the collision sentinel and, instead of pointlessly connecting to your own machine, stops and shows ERR_ICANN_NAME_COLLISION.

So the error is not the website talking. It’s your own resolution path telling you that the name you used points somewhere it shouldn’t.

Top 3 Causes

An internal-only TLD that collides with the public DNS — Someone built the network around a made-up top-level domain: .corp, .home, .mail, .lan, .dev, .local used loosely, or similar. ICANN’s security committee flagged .corp, .home, and .mail as high-collision-risk and they were never delegated — but plenty of others were delegated as real gTLDs. Once the public root answers for the string, your queries can escape the intranet and hit a zone under controlled interruption. The tell: everything under one specific TLD breaks at once.
A DNS search domain expanding a short, unqualified name — You typed a bare host like intranet or wpad. Your resolver has a search list and appends a suffix, turning it into a fully-qualified name that now collides with a delegated TLD or a controlled-interruption zone. The tell: it broke after joining a new network or changing DNS servers, and only short names are affected while fully-qualified ones work.
A stale internal name after a public delegation — A name that resolved to an internal server for years starts returning 127.0.53.53 because the matching TLD graduated to the public root and entered its 90-day interruption window. Nothing on your side changed; the global namespace did. The tell: it “just stopped working” with no local change, right around when a new TLD went live.

Diagnose with DechoNet

DNS Lookup resolves the exact fully-qualified name from outside your network and shows you what the public DNS actually returns. If the public answer is 127.0.53.53, you’ve hit a controlled-interruption zone — the TLD is now real and public, and the fix is to rename off it. If the public DNS returns a normal record (or the name is a genuine public site), then your local box seeing 127.0.53.53 means something on your side — a search domain, a hosts entry, or an internal resolver — is injecting the collision. If the public DNS returns nothing for the string at all, the name only ever existed on your network and a search suffix is turning it into a colliding one.
HTTP Check fetches the fully-qualified name from outside entirely. A clean external result while Chrome shows the collision confirms the problem is your local resolution, not the destination.

Resolution Checklist

Confirm the address first. Run nslookup <name> (or ping <name>) and check whether it returns 127.0.53.53. If it does, this is a name collision, full stop — not a server outage.
Identify which name collides. Note the TLD or the short host that triggers it, and whether fully-qualified names work while bare ones don’t (that points at a search domain).
If you own the network and use a made-up internal TLD, move off it. Put internal names under a real subdomain of a domain you control (svc.internal.example.com) or, for home networks, under .home.arpa. Don’t invent a new TLD — the next delegation round can collide with it too.
If the collision is with a TLD that genuinely went public (.dev, .app, and others are real), you cannot keep the name — rename the internal service. Fighting the global root is not an option.
Fully qualify the name so the resolver stops appending a search suffix (a trailing dot, or the complete domain), and remove stray search domains you don’t need.
Clear the caches after any change: chrome://net-internals/#dns (Clear host cache) and your OS resolver cache. The 127.0.53.53 answer can linger until TTLs expire.

When to Escalate

If your whole organization uses an internal TLD that now collides, this is a network-and-naming project, not a browser fix — hand it to whoever owns DNS. They need to renumber internal names onto a delegated domain you control, which touches DHCP search lists, certificates, and every hardcoded short name.
If a name that used to reach an internal service now returns 127.0.53.53 with no change on your part, confirm with your DNS team whether a matching TLD was recently delegated and is in its controlled-interruption window; the only durable fix is renaming the service off the colliding string.
If short names collide only on certain networks (office vs. home vs. VPN), the difference is the DNS search domain each network pushes — take it to whoever manages those DHCP and resolver settings.