Note that Chrome has no logic specific for dev domain conflicts here - it returns ERR_ICANN_NAME_COLLISION whenever a DNS lookup returns 127.0.53.53.

[+eroman, +edwardjung] for thoughts on making the error text better (See chrome://network-error/-166 for what the page looks like)

Reporting ERR_ICANN_NAME_COLLISION in this case is correct. You can read more about the ICANN policy here at https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf

Your DNS resolver has returned 127.0.53.53 specifically to advertise this dangerous usage.

If your expectation is that http://testdomain.dev/ be served from localhost, that simply isn't the case anymore, and you are operating with a dangerous setup.

Right now your DNS resolver is returning 127.0.53.53 to warn about this, but at any time in the future, http://testdomain.dev (or whatever other .dev you are using) may be served from a remote end point. It may even have valid certificates. Needless to say, this opens a pretty big hole for MiTM.

In the new of TLDs, one should use .localhost rather than .dev if you want to resolve names locally. Please report the bug to pow.cx or other dependencies you rely on.

If you really want to continue using YYY.dev as an alias to localhost (which is going to become increasingly broken so consider this just a temporary workaround) you could:

 (1) Map yyy.dev in your hosts file to 127.0.0.1

or for a Chrome-specific solution, launch with:

 (2) --host-resolver-rules="MAP *.dev 127.0.0.1"


Note that ALL applications are going to be affected by .dev being opened up, not just Chrome. (The only difference is that during the probationary period while resolvers are returning 127.0.53.53 as a warning, Chrome indicates a failure to help users track down these broken dependencies).

As far as changing the error text I am open to ideas, but this is more of a network administrator concern.

How common will this be happening to justify making changes specific for this dev case? I'm guessing it's hard to know since we don't distinguish between this error and actual name collisions.  

This should only happen on cases where a TLD conflicts with a local domain.  In 95% of cases, it's probably when a new private TLD is conflicting with a local domain that existed before the private TLD did.

The current suggestion to ask for sys admin support still applies to most cases, so suggest not making any changes for now and monitoring bug reports. 

Maybe there should be some Chrome DevRel communication about the insecure .dev setup if there hasn't already been so.

Technically, 127.0.53.53 is localhost (as this IP address is localhost) and if Chrome does not indicate this as an error, normally this address could be served by localhost. This is not a broken expectation, because this is how the 127.0.0.0/8 IP range usually works.

To be precise, .dev resolves to this address a far before you added this "conflict" error displaying to Chrome. Previously .dev domains worked well with this way. More back in the time before Google registered this TLD, .dev was a commonly used domain by developers. Again, I still think you should honor current .dev TLD users and don't break our setups. 

As far as I know .dev TLD is intended to used privately by Google and also managed by Google. So currently the only entity that can do MiTM attacks or other things is Google. Or Google considering to open .dev domain registration process to public entities (individuals or companies)?

Also, I don't think Google wants to hold and use all possible domains in .dev and definitelly don't think you want to open these endpoints to public. 

Here is my suggestion: if there is a valid name collision (so if there is a something.dev that does not drop NXDOMAIN) then display a name collision error, otherwise let us do our job as it done before. But please do not drop a name collision error if there is no name collision. Just because you own a TLD it does not means a name collision.

We do not know that dev would normally be localhost, and not something else on the local network (Or something further afield), when we get 127.0.53.53, so just assuming you really want localhost when we see it doesn't work.

If I want other things than localhost, then I can override it with a local DNS server. However, you block the whole .dev TLD blindly, regardless what I really want. Please don't want to protect me from myself. If I want to shoot myself on feet, please let me do. Chrome/Chromium is not even a part of the gun.

Chrome itself has no explicit test for dev domains - the DNS server we're using (Which we get from the system) is what's returning 127.0.53.53.

To re-iterate, there is no special treatment of .dev domains.

Your setup is incorrect, and I suggest you read the paper in comment #3.

You are hitting a DNS resolver that is returning 127.0.53.53 as a warning.

At any moment, that could IP result could change. Instead of 127.0.53.53 it may be some other public IP. Now when you load http://testdomain.dev/ you will see someone else's website. This will happen on all devices, all platforms, all browsers, with no change on your part.

You could use another browser (which may buy you some more time before a DNS level change breaks it further) or reconfigure your internal DNS if you like, however why not just fix your configuration and switch to an actual localhost domain?