.dev domains not accessible in latest Chrome

[thomasklemm]

Hi,

One day to another, .dev domains stopped working in my Google Chrome. Instead of directing the request to pow, the page is requested from the web, which results in a useless DNS error page from my DSL provider.

Accessing the apps in Firefox still works as expected, so I believe that some recent changes in Chrome, maybe related to #386 could be causing this issue. Could anyone give some help in debugging this issue?

Chrome 27.0.1453.116
Current pow release installed and updated with powder.

[danphilibin]

+1, also happening to me all of sudden. Works fine in Firefox and Safari, but Chrome just whisks me away to a DNS error page.

Curiously, one pow application still loads in Chrome, but none of the others do. Nothing unique about that one as far as I can tell.

Chrome 28.0.1500.71
Tried reinstalling pow and re-creating the symlink.

[mutewinter]

Same issue when running Chrome 28.0.1500.71 on Mac OS X 10.8.4.

Chrome Canary does work at 30.0.1571.0.

[mutewinter]

Just found a workaround!

Using xip.io pointing at local host fixes the problem temporarily. Here's an example:

http://broken-on-chrome.dev

becomes

http://broken-on-chrome.127.0.0.1.xip.io

[forced-request]

I've been having the same issue as well on 28.0.1500.71.

Disabling my internet connection solves the problem, but obviously isn't ideal.

[kneath]

FWIW, I ran into this issue with .dev domains (not based on pow) all of a sudden today (Chrome 28.0.1500.71 on Mac OS X 10.8.4.). I fixed it by switching to Google's DNS as mentioned here https://twitter.com/hansv/status/359794432544997378 — I had OpenDNS configured on my router so it was falling back to this.

This fix doesn't make sense to me, but maybe it helps track down the issue.

[marcroberts]

The actual fault here is Chrome's "Built-in Asynchronous DNS", disable this in chrome://flags and it'll work again.

This also affects the Blink based Opera.Next but there's currently no way to disable the Asynchronous DNS resolver in that.

[heironimus]

Turning off Chrome's "Built-in Asynchronous DNS", disable this in chrome://flags fixed it for me.

[muddymatches]

+1 for above fix disabling "Built-in Asynchronous DNS"

[stravid]

Has somebody investigated this issue further? (e.g. why does this flag break Pow?)

If it's a problem with Chrome we should report it and try to fix it. This issue is for new Pow users a major road block when trying to use it with Chrome.

/cc @sstephenson @josh

[mdkent]

Chrome is aware of the issue in https://code.google.com/p/chromium/issues/detail?id=265970 - looks like it's their fault.

[craigkeeling]

+1 worked for me, disabling "Built-in Asynchronous DNS"

[patrickarlt]

+1 disabling "Built-in Asynchronous DNS" in chrome://flags fixes this.

[tristanbes]

👍

[guidobouman]

I'm not experiencing the issue using the most recent version of Chrome (Version 29.0.1547.57)

Doesn't http://appname.dev/ work? Note that last slash.

[jgrannas]

I am having this issue in Chrome Version 29.0.1547.76. Tried the extension, tried disabling built-in async dns too. Used to work :(

Update. restarted computer and now miraculously working

[JohanLopes]

👍 disabling "Built-in Asynchronous DNS" in chrome://flags/#enable-async-dns

[dmarkow]

I had this problem earlier this year, but as of now it's working fine resolving http://myapp.dev/ on the current version of Pow with Chrome 30.0.1599.101 (OS X 10.9).

[simonhamp]

Not entirely sure why, but I am experiencing a DNS lookup delay of exactly 5s in Chrome 36.0.1985.143, which makes developing on local .dev domains frustratingly unresponsive to say the least. @marcroberts's suggested 'fix' worked for me in this case too.

I'm keen to understand further the impact of disabling this Asynchronous DNS. Can anyone shed any light onto the kind how it's going to impact my web use?

[ajb]

Having the exact same problem as @simonhamp, but the solution isn't working for me.

[simonhamp]

@ajb yes this 'fix' is no longer working for me 😞

[tomhanoldt]

...

[guidobouman]

Just add a slash behind your url. http://myproject.dev/ <-- Note that last slash. Done.

[devmarwen]

Google removed the link to toggle "Built-in Asynchronous DNS" in chrome://flags/

Any other solution?

[devmarwen]

Using dnsmasq helped fix the problem.

[johnwarne]

@devmarwen I've been dealing with "Resolving host…" in Chrome for years for .dev domains. This solution has fixed this problem. Thanks!

[webprogrammierer]

None of the above solutions works in Chrome 63.
Is there any solution?

[jeremy]

Solution: switch from .dev to .test: https://github.com/basecamp/pow/blob/master/MANUAL.md#configuring-top-level-domains

[MurKit]

"Built-in Asynchronous DNS" no longer works.
I don't want to switch to .test
How to disable this forcing of .dev and .foo?

[lecktor]

Seems, that it is impossible to change .dev to something in dnsmasq by default

[thelonewolf]

This is ridiculous. Why does chrome not look to my host file for where this domain is located anymore. plus it is trying to force https on my local dev. I am using .dev and I do not want to switch to .test. Google fix this.

[tristanbes]

@thelonewolf you should read about HSTS and edit your comment before passing for a fool
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[thelonewolf]

@tristanbes Thanks I think, for the link. However I understand what HSTS is, I did research on it when I ran into this issue, and I'm sorry if my response was not as detailed as it could have been, this is not the first posting I have found on this subject. Second this is for LOCAL DEV work and is not a security issue or really even related to HSTS because you can use .test as the TLD and Chrome works as expected.

After more research the only reason Chrome is doing this for .dev TLD's is because Google bought it, and have added something to Chrome to not even look at the local host file for that TLD before reacting to it.

If you read others comments here too you would see that I am not the only one that disagrees with what Google is doing, and yes it is only Chrome that is doing this. I tested the other browsers latest versions and no problem what-so-ever. Even though having to have SSL on a local dev seams ridiculous, I set it up anyways with a self signed cert (I'm not going to get a third party cert for my local dev work, that is not called for). This works in the other browsers you just have to tell them the cert is ok for the testing domain, but not in the latest version of Chrome, just no access.

I have no complaint with Chrome trying to be safe and enforce HTTPS for production websites, but it should know that the domain name is pointed to 127.0.0.1 which I believe equals localhost on pretty much all machines. If it sees that, it should not force https or at the very least it should give you the option to tell it, it's ok, or that it is a local dev site, instead of effectively blocking all access to it.

After much searching for a work around there are two options, (1) screw chrome and not test in it and just hope that after testing in the others that chrome will render everything correctly, or (2) updated dozens of dev sites to use .test instead, and ask Google to rethink their decision.

Even though option one is what I would like to do, for obvious reason that is not going to happen. So instead option two, use .test and hope that Google will see all the posts on this issue and rethink their actions (probably not but worth a try).