Chrome ignoring hosts file for subdomains of localhost

Question

When I attempt to visit http://mysubdomain.localhost chrome resolves to [::1]80, even if there is an explicit entry for this domain in the hosts file. No other browser behaves this way. Firefox, safari, and curl all resolve the IP address given in my hosts file. This is the entirety of my hosts file at the moment:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
192.168.88.88  mysubdomain.localhost

And yet, when I attempt to visit http://mysubdomain.localhost in chrome, it does not resolve to 192.168.88.88. This is problematic for me, because 192.168.88.88 is a virtual machine running on my computer. I could change the domain to http://mysubdomain.local or http://mysubdomain.dev, but that would require me to update a configuration file used by many people on the project, which I'd rather avoid, because I may break some aspect of their workflow.

Firefox (working as desired)

curl (working as desired)

Chrome (not working as desired)

Some things I've already tried:

• I am not using a proxy
• I have cleared browser cache many times
• I have cleared dns cache from chrome://net-internals/#dns
• I have restarted the machine several times
• I have cleared the system DNS cache with the terminal command sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder
• I have tried incognito mode several times
• I have tried created a new chrome user account

System information:
Chrome version: 53.0.2785.116
OS Version: Mac OS 10.11.6 (El Capitan)

Answer 1

Upon further review, I think this is unfortunately working as designed. From the chromium issue queue:

This was done as a security mitigation, as OS X's resolver does not properly ensure that .localhost domains are not queried on the network, which is a key security property of ensuring .localhost is truely local. Because we can't trust the resolver to do the secure thing, we unfortunately can't trust the resolver (even when it may be secure)...

The security risk is not about properly configured server vs improperly configured server. It's that a DNS resolver should never send foo.localhost requests out to the network. If it does, a network attacker could make "foo.localhost" point to any IP of their choosing. This is bad, because "localhost" (and "*.localhost") have special privileges (c.f. http://www.w3.org/TR/powerful-features/#is-origin-trustworthy ), and because they have those special privileges, they need to be secure.

In fact, it seems that chrome may be the only tool in the bunch properly implementing RFC-6761 which states in part:

Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

So it seems there is no way to fix this. I will change the domain of my virtual machine to http://mysubdomain.local

Answer 2

After playing around with this and using firefox for a while, I found a workaround by accident. Instead of changing your development environments you can simply install https://www.telerik.com/download/fiddler.

Fiddler bypasses the DNS of chrome, I believe, so you are left with a perfectly working system without having to change all your environments.

I have tested this on Windows 10 with Hyper-v over vagrant.