New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 489973 link

Starred by 21 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug-Regression

Sign in to add a comment

.localhost wont use hosts file

Reported by, May 20 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Type your localhost ending dev domain
2. Shows It works (which is the standard stuff)
3. Switch to Firefox and check the locahost ending server up and running

What is the expected behavior?
Uses /etc/hosts to lookup anything.localhost, as the previous version do it.

What went wrong?
I think Chrome wont ue /etc/hosts to lookup localhost ending domains.

Did this work before? Yes Previous version, until this morning.

Chrome version: 43.0.2357.65  Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 17.0 r0

Please fix it I need to use different browser.

Comment 1 by, May 20 2015

Looks like this is a feature:

Comment 2 by, May 20 2015

LOL This is the silliest feature ever, how can i switch off? All the previous versions are worked, it is so disappointing.

Comment 3 by, May 20 2015

I mean to ignore /etc/hosts file for localhosts :) 

Comment 4 by, May 20 2015

Labels: -OS-Mac OS-All
Status: Untriaged
Labels: -Pri-2 -Type-Bug Pri-3 Type-Bug-Regression
This is caused by as part of  Issue 455825 . 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)
Labels: -Cr-Internals-Network Cr-Internals-Network-DNS
That said, I should also mention that localhost domains are always expected to resolve to localhost (documented here - ), so this "regression" is that we are now more compliant.

It is the same way you "shouldn't" be able to change "localhost." to resolve to a non-local IP.

Comment 7 by, May 20 2015

I'm not quite understand this, because
http://localhost goes through and give me the dummy / default result
http://anysite.localhost mapped to ( /etc/hosts and give me the localhost's dummy / default result, instead of goes to the server as other browsers do.

If we speak about security risk, why I can reach localhost which (because the default settings) could be more insecure rather than a properly set webserver. Plus why *.localhost resolved with localhost instead of an error message. 

I understand that you disable the access from to *.localhost it makes sense. But why I can't navigate to my local sites in the address-bar and keep myself on same domain?

anyway if it is a feature it is time to leave Chrome because I have not time to set up all my dev servers. It is quite strange to be honest it was an automatic update with braking change and there is no button to revert.
Correct, "anything.whatever.localhost" is all treated as localhost. *.localhost -> localhost. That's what's defined in RFC 6761 - that is, that "localhost." (and subdomains) map to the local loopback

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. ), and because they have those special privileges, they need to be secure.

This is nothing about not being able to talk to *.localhost. While Issue 378566 is tracking that, this is not the cause for your issue.

Because of the varying quality of the OS DNS resolvers, before we ask the OS (which is responsible for reading /etc/hosts, as well as sending the actual DNS requests, consulting things like NETBIOS, mDNS, etc) to resolve a domain, we first ensure that the domain is valid according to the rules of DNS. For example, you can't resolve "" (note the two dots), even though for some naming systems, and some OSes, that's "valid".

It's a complex topic, but ultimately, the goal is to ensure a consistent, secure experience regardless of the OS you're using, and a consistent, secure experience that follows the relevant Internet standards. "anysite.localhost" mapping to anything other than a loopback address (, [::1]) is one way to violate those standards, hence why it's no longer allowed.

Comment 9 by, May 20 2015

Ok, I never thought that. I was quite happy with Firefox today, so until I got these *.localhost -s I can't use Chrome. Bit annoying but I understand. Thanks
I read these specs and I agree localhost must be just localhost. Thanks guys to explained that! It was a bad surprise. As soon as I got some time I'll move everything out from localhost. Thanks again.
 Issue 490679  has been merged into this issue.

Comment 12 by, May 25 2015

If there is an OS vulnerability with DNS lookup, it seems like the OS manufacturer should address it rather than an application like Chrome.
For developing and testing purposes I use subdomains on localhost with entries in my hosts file like myapp.localhost sub.myapp.localhost

This worked until Chrome 42.

If this is was a security feature the browser should not go wild and try to reloading this address permanently. It should point out, that it is not willing to connect.

On the other hand, there should not be a problem if myapp.localhost points to 

Well for a workaround I changed localhost to something else in my hostst file and everything is nice again.

Only cases were localhost is routed outside should be blocked (with a clear warning - message!)
Re: comment 13: Such a config should work. All *.localhost resolutions should resolve to the loopback address (e.g. localhost). If this isn't working, could you file a new bug and include a net-internals log?

See for directions.

This only applies for cases where a .localhost domain was routed to the loopback adapter.
Status: WontFix
Just to be explicit - Closing this as a "WontFix" for the "Works as Intended" (or at least, the relevant specs dictate such behaviour is perfectly acceptable, and the alternative is security risky)
Same problem with Ubuntu 15.04.
No problems until Chrome 42.

Comment 17 Deleted

Comment 18 Deleted

Comment 19 by Deleted ...@, Jun 24 2015

i don;t understand if there's security risk, why chrome not just pointing "anything.has.localhost" to local?
Re #19, that is what Chrome does now (resolves foo.localhost to
#20 It would be good, but for me (and maybe for others) it says: ERR_NAME_NOT_RESOLVED. That's why we here.

Comment 22 by Deleted ...@, Jul 3 2015

Just for the record, I had the same problem reported by Comment #13 and I fixed it 
adding " localhost." to the /etc/hosts (note the trailing dot) as indicated by @rsleevi in, commment #2.

This change breaks resolution of other loopback addresses:

Hosts file:	phpmyadmin.localhost	site1.localhost	site2.localhost	site3.localhost	site4.localhost

Those addresses are valid Loopback addresses on Windows and so should be allowed by Chrome, but it never gets that far.

Re: #23, that should not be the case on ToT. checks the hosts file first for local hostnames, and resolves them to if they are not resolved in the hosts file.
I tested on Canary (45.0.2454.6, revision e681ad07907c49ee2f3dda78be0b9f029c806868-refs/branch-heads/2454@{#7}) and I see the same issue.

I attached a screenshot showing the behavior. The default Apache page shows up instead of phpmyadmin because the resolution is not being done.

It is possible something else is going on. If it is being resolved through the hosts file or any other regular method, I would also expect to see it in chrome://net-internals/#dns as well as in chrome://net-internals/#events&q=type:HOST and it is not showing in either place. A copy of the relevant events I do see is attached.
Chrome dot.localhost resolution.PNG
120 KB View Download
Chrome events.txt
3.8 KB View Download
Re #25, thanks, I think I see what's happening. Filed issue 510124 (though unfortunately, at the moment, I'm not sure how we can fix this while still avoiding trusting the system resolver with local hostnames).

Comment 27 by Deleted ...@, Jul 23 2015

Thanks to (comment #22) - adding localhost. (with trailing dot) to hosts file fixed the issue for me (Ubuntu).

Comment 28 by, Jul 28 2015

Comment #22 also fixed this for me. Thanks

Comment 29 by Deleted ...@, Aug 5 2015

I also had this issue, and not the behavior described in #20. The fix in #22 is a sufficient workaround.

Sign in to add a comment