This repository has been archived by the owner. It is now read-only.

`.dev` domains not accessible in latest Chrome #397

Closed
thomasklemm opened this Issue Jul 20, 2013 · 32 comments

Comments

Projects
None yet
@thomasklemm

thomasklemm commented Jul 20, 2013

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

This comment has been minimized.

danphilibin commented Jul 21, 2013

+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

This comment has been minimized.

mutewinter commented Jul 21, 2013

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

This comment has been minimized.

mutewinter commented Jul 21, 2013

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

This comment has been minimized.

forced-request commented Jul 23, 2013

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

This comment has been minimized.

kneath commented Jul 23, 2013

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

This comment has been minimized.

marcroberts commented Jul 24, 2013

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

This comment has been minimized.

heironimus commented Jul 24, 2013

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

@muddymatches

This comment has been minimized.

muddymatches commented Jul 31, 2013

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

@stravid

This comment has been minimized.

stravid commented Jul 31, 2013

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

This comment has been minimized.

Member

mdkent commented Aug 5, 2013

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

@craigkeeling

This comment has been minimized.

craigkeeling commented Aug 10, 2013

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

@patrickarlt

This comment has been minimized.

patrickarlt commented Aug 15, 2013

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

@tristanbes

This comment has been minimized.

tristanbes commented Aug 22, 2013

👍

@guidobouman

This comment has been minimized.

guidobouman commented Aug 24, 2013

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

This comment has been minimized.

jgrannas commented Sep 27, 2013

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

This comment has been minimized.

JohanLopes commented Oct 16, 2013

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

@dmarkow

This comment has been minimized.

dmarkow commented Oct 24, 2013

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

This comment has been minimized.

simonhamp commented Aug 15, 2014

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

This comment has been minimized.

ajb commented Oct 17, 2014

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

@simonhamp

This comment has been minimized.

simonhamp commented Oct 17, 2014

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

@tomhanoldt

This comment has been minimized.

tomhanoldt commented Feb 2, 2015

...

@guidobouman

This comment has been minimized.

guidobouman commented Feb 2, 2015

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

@devmarwen

This comment has been minimized.

devmarwen commented Nov 3, 2015

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

Any other solution?

@devmarwen

This comment has been minimized.

devmarwen commented Nov 3, 2015

Using dnsmasq helped fix the problem.

@johnwarne

This comment has been minimized.

johnwarne commented Jun 29, 2016

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

@webprogrammierer

This comment has been minimized.

webprogrammierer commented Dec 17, 2017

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

@jeremy

This comment has been minimized.

Member

jeremy commented Dec 18, 2017

@MurKit

This comment has been minimized.

MurKit commented Dec 22, 2017

"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

This comment has been minimized.

lecktor commented Dec 22, 2017

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

@thelonewolf

This comment has been minimized.

thelonewolf commented Jan 5, 2018

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

This comment has been minimized.

tristanbes commented Jan 5, 2018

@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

This comment has been minimized.

thelonewolf commented Jan 6, 2018

@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).

@basecamp basecamp locked as resolved and limited conversation to collaborators Jan 6, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.