And the relevant line:  https://cs.chromium.org/chromium/src/net/dns/host_resolver_impl.cc?sq=package:chromium&dr=CSs&rcl=1484914567&l=2103

I'm grabbing this, if you don't mind. :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da1c690ec8023df8967c8b15ca8f70bdffa693a4

commit da1c690ec8023df8967c8b15ca8f70bdffa693a4
Author: Mike West <mkwst@chromium.org>
Date: Sat Aug 12 05:57:16 2017

Special-case `localhost` resolution.

As recommended in [1], this patch changes `HostResolverImpl` to
special-case resolution of localhost names, bypassing both the cache
and any relevant HOSTS files to return IPv6 and IPv4 loopback addresses
without consulting the underlying recursive resolver.

[1]: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost

Bug:  683213 
Change-Id: I24708b3e17ac3e96b46f38f28e129c2def364950
Reviewed-on: https://chromium-review.googlesource.com/598068
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493964}
[modify] https://crrev.com/da1c690ec8023df8967c8b15ca8f70bdffa693a4/net/dns/host_resolver_impl.cc
[modify] https://crrev.com/da1c690ec8023df8967c8b15ca8f70bdffa693a4/net/dns/host_resolver_impl_unittest.cc

This change was breaking our development workflow. We have been using *.localhost to resolve to a virtual machine IP address and all of a sudden it has stopped working. I get it that localhost should always point to loopback interface in that document, but it didn't mention anything about *.localhost. 

Per section 2 of that doc:

The domain "localhost.", and any names falling within ".localhost." are known as "localhost names".

However, it doesn't mention localhost6, localhost.localdomain, or localhost6.localdomain6, which we also give magic treatment to.

Is there any reasons for the change? That document is still a draft, why applying the change to stable release?

Btw I'm sorry if this is not relevant to the original thread, but would like to understand more the story behind the changes.

It's actually been Chrome's behavior for about 18 months - the fact that it didn't apply when using the hosts file, on a subset of platforms, was just a bug.  The reason is so that localhost can be treated as secure by default (For things like insecure warnings, and allowing ServiceWorker, I believe?  Not my area)

Thanks for the explanation. It's weird that I just experienced the issue, maybe my version is behind for whatever reasons. I believe this is not something that can be changed in the settings? Anyway, I've been changing all the *.localhost to something else like *.dev for the development purposes.

Thanks again.

You're right that this isn't something that can be changed in settings.

The reason why you're only running into it now is that we use our own stub DNS resolver on a couple platforms, and due to a bug, when using it, the hosts file would take precedence over the localhost magic.

dev also doesn't work, for a different reason - dev is now a globally registered domain.  I believe "local" is reserved for this purpose (That is, no one can register it out from under you).

I see. Yeah I'm on linux. I started seeing the behaviour on Windows and thought that it was the OS, but isolated it to Chrome only behaviour.

Thanks for the heads up on the domain. Will be using .local instead. I wasn't aware of .dev being a valid top level domain until now.

I wish ICANN hadn't allowed folks to reserve things like `.dev`. It's a world of hurt. :( `.local` should work for you. It's reserved for multicast DNS by https://tools.ietf.org/html/rfc6762, so it might have special behavior on some platforms (like macOS). It sounds like the IETF is also considering reserving `.internal` for the more general use-case you're dealing with, adrian@: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00. Either of those should be safe.