6

After a recent Chrome update to v73, Chrome no longer uses my hosts file for IPv6 addresses. I have an entry like:

::1    some-project.test

Trying to go to https://some-project.test results in ERR_NAME_NOT_RESOLVED. If I change the entry to 127.0.0.1, the hostname resolves.

There's no problem with my hosts file entry. It's worked fine for months on previous versions of Chrome. I can ping some-project.test. Firefox works fine. I can even run a proxy like Fiddler and Chrome can access it that way. I just can't use Chrome directly.

Any suggestions for working around this?

Update: It seems dependent on the network I'm connected to. After moving from a public WiFi network back home, this is working again. I'm not sure how that's possible... shouldn't the hosts file override anything in DNS? And, shouldn't Chrome be using the system resolver anyway? Everything else on the system does and works fine.

Update 2: Back on home wired Ethernet... broken again. The problem is intermittent.

Brad
  • 6,182
  • I can confirm Chrome 73 absolutely uses the hosts file on Windows. There is some other unidentified reason you are unable to navigate to the .test domain you have configured. – Ramhound Apr 04 '19 at 22:12
  • @Ramhound It's using the hosts file for me, but not for IPv6 entries. It only works for IPv4 entries in the hosts file. Can you confirm that IPv6 hosts file entries are working for you in Chrome v73? Thanks. – Brad Apr 04 '19 at 22:14
  • According to https://stackoverflow.com/questions/42636711/google-chrome-ignoring-hosts-file, Chrome doesn't like .test for some uses of the Hosts file. Try some-project.local instead, just to rule that out. – Doug Deden Apr 04 '19 at 22:26
  • @Brad - Then as somebody as specified it's the name of the domain your using not the fact it IPv6. Chrome 73 absolutely still uses the hosts file for both IPv4 and IPv6. Related – Ramhound Apr 04 '19 at 22:29
  • @DougDeden Using something.local or even just something doesn't work. Additionally, something.test works just fine for IPv4 addresses. It also worked fine for IPv6 addresses yesterday. – Brad Apr 04 '19 at 22:37
  • @Ramhound It's not a caching issue. Cache has been cleared and I'm usually operating with my dev tools open anyway with cache disabled. The hostname isn't resolving... I'm not even getting to a point where the cache could be used. No matter what name I try, it doesn't work for IPv6. – Brad Apr 04 '19 at 22:39
  • You flushed the cache after you change it to something.local and obviously made the required changes to your web project? – Ramhound Apr 04 '19 at 22:45
  • @Ramhound Yes, yes. Just updated the question... turns out this starts working again after switching networks. Very strange behavior. – Brad Apr 05 '19 at 05:12
  • @davidbaumann Yes, pinging works fine, as mentioned in the question. So does everything else. Just Chrome seems to be the issue. – Brad Apr 05 '19 at 14:27
  • Since only IPv6 has problem on some networks, is it possible that these networks do not support IPv6? – harrymc Jun 24 '19 at 15:57
  • @harrymc The problem is intermittent on some networks, whether they support IPv6 or not. And, I would expect ::1 to always work anyway, as I have IPv6 enabled on my machine. Indeed, ::1 works, and the hostnames work in all applications except Chrome intermittently. – Brad Jun 24 '19 at 15:58
  • Does Chrome give an error code when it fails? – harrymc Jun 24 '19 at 16:04
  • @harrymc Yes, ERR_NAME_NOT_RESOLVED. – Brad Jun 24 '19 at 16:05

2 Answers2

9

There is a know bug in Chrome which might be responsible for your problem:
Issue 530482: Can't reach private IPv6 hosts on networks without global IPv6 connectivity.

The discussion in the bug report clarifies that Chrome launches an IPv6 probe to determine if there is IPv6 support, by checking with a remote address. If that IPv6 probe fails, Chrome will mask out any other IPv6 results, in effect disabling IPv6 and ignoring it forever.

The explanation is then that if IPv6 support is sketchy on the network, so that this single initial IPv6 probe done by Chrome fails, Chrome will just disable IPv6 resolving totally, including local IPv6 resolving from the hosts file.

A workaround mentioned is:

Add a network route to 2001:4860:4860::8888. Doesn't have to actually be functional (could just drop requests to it). As long as Chrome can connect a UDP socket to the address, it will pass the heuristic checking IPv6-connectivity and allow AAAA DNS queries and IPv6 resolve results.

Other more limited workarounds are mentioned at the end of the bug report.

The bug report dates from 2015, but was still alive in May 2019, so it may perhaps be currently in process.

harrymc
  • 480,290
  • 1
    Awesome! Thanks for digging this up. I'm sure that's going to be it. I'm going to experiment with some of the workarounds and see. Will accept the answer later if this works out. – Brad Jun 24 '19 at 16:54
  • 3
    Yep, that worked. net sh, interface ipv6, add route 2001:4860:4860::8888/128 interface=1. – Brad Jun 24 '19 at 17:10
  • 1
    @Brad - Thanks so much for this. I've been banging my head against the desk trying to get Chrome to connect to hosts via my office's IPv6 VPN. I added that route and voila, it worked instantly. – oobayly Apr 02 '20 at 14:19
  • For anyone else who finds this, the command is actually netsh, not net sh – user125355 Jun 03 '20 at 19:27
  • On linux, you can use sudo ip route add 2001:4860:4860::8888/128 dev lo. – ki9 Apr 05 '21 at 02:39
0

Your hosts file should be consistent, eg; localhost is 127.0.01. Then some-project.test should also be available on 127.0.0.1, and since the IPv6 address ::1 typically, and traditionally also points to localhost, and the IPv4 address 127.0.0.1. As not all systems are necessarily IPv6 capable -- yes, even in this day, and age. :)

The problem, like localhost is that test is a TLD (just like .com).

My suggested hosts file:

# following 2 entries are *optional*
::1    localhost
127.0.0.1    localhost

::1    test project.test
127.0.0.1    test project.test

See what I'm talking about? Some applications (and OSs) assume a localhost "host". So you may find you require an entry for it -- see; optional in the example above.

Lastly. Make sure your resolver flushes it's DNS cache. As to your system. It should see the change(s) immediately. But you should check first.

somebody
  • 540
  • 2
  • 9
  • My question has nothing to do with localhost. My system supports IPv6 just fine. All other applications on the system can resolve my hostnames just fine. Even Chrome works through a proxy on the same machine. And, there is absolutely nothing wrong with using .test... it's the prescribed way, as indicated by RFC2606. Also, yes, I've flushed DNS caches and the Chrome resolver cache. – Brad Jun 24 '19 at 01:41
  • StackExchange speaks to a broad audience. As such, I chose to make my answer as detailed as necessary to answer not only your specific question. But also to others with a similar question. I can not presume to know the depth of knowledge that either you, or others posses. I can only infer. Which is not a very reliable position to take. What you didn't address in your reply. Is to whether my proposed hosts file did, or didn't work. I will not make an assumption in this regard. As that has at best, a 50% chance of being correct, as being incorrect. – somebody Jun 24 '19 at 03:07