tl;dr: Chrome 63 (out since December 2017), will force all domains ending on .dev (and .foo) to be redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.
Update 07/02/2018: Firefox now also forces .DEV domains to HTTPS.
This very interesting commit just landed in Chromium:
Preload HSTS for the .dev gTLD.
This adds the following line to Chromium's preload lists;
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },
It forces any domain on the .dev gTLD to be HTTPs.
Wait, there's a legit .dev gTLD?
Yes, unfortunately.
It's been bought by Google as one of their 100+ new gTLDs. What do they use it for? No clue. But it's going to cause a fair bit of confusion and pain to webdevelopers.
The .dev gTLD has nameservers and is basically like any other TLD out there, we as developers just happen to have chosen that name as a good placeholder for local development, too, overwriting the public DNS.
$ dig +trace dev. NS dev. 172800 IN NS ns-tld4.charlestonroadregistry.com. dev. 172800 IN NS ns-tld5.charlestonroadregistry.com. dev. 172800 IN NS ns-tld3.charlestonroadregistry.com. dev. 172800 IN NS ns-tld2.charlestonroadregistry.com. dev. 172800 IN NS ns-tld1.charlestonroadregistry.com.
Google publishes some of their domains on there, too;
$ dig +trace google.dev A google.dev. 3600 IN A 127.0.53.53
So yes, it's a legit TLD.
Consequences of redirecting .dev to HTTPS
A lot of (web) developers use a local .dev TLD for their own development. Either by adding records to their /etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to 127.0.0.1.
In those cases, if you browse to http://site.dev, you'll be redirect to https://site.dev, the HTTPS variant.
That means your local development machine needs to;
- Be able to serve HTTPs
- Have self-signed certificates in place to handle that
- Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)
Such fun.
What should we do?
With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else.
If you're looking for a quick "search and replace" alternative for existing setups, consider the .test gTLD, which is a reserved name by IETF for testing (or development) purposes.
There's also an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.
I do hope the Chromium team reconsiders the preloaded HSTS as it's going to have rather big implications for local webdevelopment.
Comments
Hanno Sunday, September 17, 2017 at 12:03 -
A few comments from me.
First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway.
But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated.
Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)
Weldon Sunday, September 17, 2017 at 15:36 -
@Hanno I think it’s silly to pay a CA for a development certificate. Even with the free services it’s silly; there’s literally nothing to be gained by having a third party “verify” your own identity to you. The right solution there is to implement an internal CA (which you should really be doing anyways) and install its signing certificate on your local browsers. Then you can secure anything you want locally, including just IP addresses.
DevSecOps Jones Sunday, September 17, 2017 at 17:43 -
There is no cost to LetsEncrypt certificates, and using these is Development is appropriate.
The hosts need not be reachable from the internet, you can use DNS records to prove domain ownership.
I would be recommending use of globally trusted, gratis certificates on dev from LE.
The certificate issuance process should use different key material for prod,
but should be configured in the same way.
Ideally production and development instances of your site should be created using a similar process but with different data sets.
Fernando Sunday, September 17, 2017 at 18:52 -
You dont always want to expose your project names to public DNS or CT logs.
also, Lets Encrypt API limits are so low , that using it in dev mode, would exhaust it in just 5 deploys.
a better idea is to use something like hashicorp vault for CA management.
Anmol Sunday, September 17, 2017 at 21:57 -
The API limits are not that low? Just don’t recreate a new certificate every time you launch the app, reuse old ones.
Weldon Monday, September 18, 2017 at 22:04 -
There’s no financial cost to LetsEncrypt, but now you’re adding a trust dependency that you don’t have if you just run your own internal CA for internal PKI. It’s really surprising to me that apparently a lot of companies don’t do this; I had assumed it was universal.
JB Friday, November 10, 2017 at 15:40 -
Hanno,
since you highlighted this discussion in your latest newsletter, you need to understand that there are some very solid reasons for using unencrypted connections to physically secured (or not) test servers:
A) The connection is so physically secure that no amount of crypto or DNS can do anything but hurt security. This is the case when mapping to 127.0.0.1 or any other address on or near your own machine.
B) To debug the plaintext protocol carried over TLS etc. it is often necessary to inspect the packets with a tool such as tcpdump or WireShark. Encryption (and especially PFS encryption) intentionally prevents that and thus must be turned off in such laboratory tests.
C) During development of a new device or server, there will often be points in time where the TLS integration has not yet been done.
D) To ensure bulletproof HTTPS implementation on a website, developers need to test the mechanisms that redirect, block or otherwise handle incoming HTTP connections. Having the browser prevent the simulated mistake prevents testing the second and third layer of defense.
Jens Monday, December 11, 2017 at 17:26 -
Stupid comment. What does google or anyone have to do with what .tld I use LOCALLY on MY MACHINE ? Think before you speak!
Googles “nice guy” halo is really starting to look crooked. They make a lot of weird decisions affecting everyone on the web just because they can.
ivan Thursday, December 14, 2017 at 18:25 -
you are right!!, this really sucks while working locally, it does’nt really make sense!
max Tuesday, December 19, 2017 at 22:44 -
Agree I have a new problem to deal with today.
leo Tuesday, January 16, 2018 at 07:09 -
Hell, you think that dev is stupid.
But using hsts for no reason – that’s just disgusting. Moreover, it breaks things.
Dave Sunday, February 11, 2018 at 16:11 -
Well I’ve been using .dev for almost 20 years and using development certificates issued by my own internal CA for almost as long. It has made its way into so much development infrastructure that it will take me weeks to move to some other domain name (only to find that ICANN greed results in that becoming a new TLD down the track).
Your suggestion to use a subdomain of some real domain is pretty stupid if I don’t own any real domains, and paying for wildcard certs for a client’s temporary development is even more absurd when the TLS in this instance is unwanted in the first place and when the site’s only user is me on localhost or in a VM.
While I have been frustrated for several hours by this strange behaviour of all my browsers (which is why it took so long to diagnose), now that .dev is a TLD I can’t really complain about the HSTS treatment by its owners.
What is annoying is that the behaviour was silent and that it was triggered despite me having never visited the (now real) .dev domain and been sent a protocol upgrade redirection.
Incidentally my choice of .dev for internal development back in the 90’s wasn’t random. At the time using .dev was as safe as 192.168 – it was ensured by the ISI NEVER to be a TLD because NetNames and Network Solutions hadn’t yet turned the domain registration system into a squatters paradise and global namespace hierarchies still made some sense (excluding the special treatment given to the US). Basically the Internet was still managed by computer scientists instead of millennials, hipsters and porn moguls.
Dawesi Sunday, August 19, 2018 at 14:47 -
Forcing https makes both firefox and chrome non-standard browsers.
Making a policy on a domain, and forcing a browser to obey it are two worlds that should never meet according to standards.
Another example of Google abusing their godless powers to do evil.,
leonixyz Sunday, September 17, 2017 at 12:09 -
another solution: change browser
Michal Špaček Tuesday, September 19, 2017 at 19:56 -
Which one? The same HSTS preload list is used for Chrome (and Chromium-based browsers), Firefox, IE/Edge, Safari and probably some more. Sooner or later all these will force HTTPS for .dev.
Octav Tuesday, January 2, 2018 at 15:32 -
Firefox doesn’t force you to use SSL for .dev
Gareth Wednesday, February 7, 2018 at 14:31 -
It does as of today
Og Astorga Wednesday, February 7, 2018 at 20:48 -
Sadly this is true, Firefox now forces https in .dev domains
MIlan Friday, February 23, 2018 at 05:30 -
Not my Firefox, and it’s updated
Wally Monday, March 19, 2018 at 18:44 -
Firefox 59 does. I now have to reconfigure my entire development environment because web browsers are forcing something that should only be enforced by servers.
What’s most annoying about this hoopala over the TLD name, is that “.dev” best describes what I’m doing: Development. “.test” better describes a staging server, which is NOT the same thing as a development server, and “.localhost” is an annoyingly lot of characters to have to type, not to mention it won’t “automatically work” since A) 127.0.0.1 doesn’t redirect to my virtual machine, and B) when I need to connect to the development server from a different computer on the LAN, localhost obviously isn’t the wanted location.
hintss Sunday, September 17, 2017 at 12:24 -
protip: you can type “badidea” at the https error screen to skip it, avoid using the mouse
Emil Stahl Wednesday, September 20, 2017 at 00:35 -
Yes. But you can’t skip HSTS. That is part of the whole idea 💡
anon Wednesday, September 20, 2017 at 06:07 -
You can, in fact, skip HSTS errors using the ‘badidea’ method in Chrome. Quick way to confirm is https://subdomain.preloaded-hsts.badssl.com/ , which is an HSTS enabled test page provided by the badssl.com test service. Clicking ‘Advanced’ gives you the normal text, but typing ‘badidea’ takes you to the page.
What’s interesting, most of badssl.com’s test URLs give you an actual webpage explaining why the SSL should or should not have worked. In this case, you just get an nginx error page, suggesting that perhaps even the folks at badssl.com was not aware Chrome (or anyone else) provided an HSTS bypas.
Dustin Thursday, December 7, 2017 at 22:12 -
But if you’re using .dev for development work and you’re not even server on over https, `badidea` won’t work because you just get a network connection error.
Ken Sunday, December 17, 2017 at 06:46 -
Thanks dude!
Alex Thursday, December 14, 2017 at 20:18 -
Cool, thanks, didn’t know that))
Gary Thursday, January 18, 2018 at 14:16 -
Oh my word, that is an amazing tip! I feel like I’ve just discovered the Konami code. ;)
(Also the ‘reply’ link on this site is misleading.) ;)
Mattias Geniar Thursday, January 18, 2018 at 14:22 -
Haha my bad, fixed :-)
WhyNoMas Sunday, September 17, 2017 at 18:11 -
Changing browser and recommending your clients to do so is the way to go. Chrome is now what IE used to be.
Emil Stahl Wednesday, September 20, 2017 at 07:30 -
All major browsers use Chrome’s HSTS preload list.
Kees Sunday, September 17, 2017 at 19:56 -
While I agree that this is not desirable, there is a specific TLD made for testing, .test (source: https://en.wikipedia.org/wiki/.test).
Mike Schinkel Monday, September 18, 2017 at 04:15 -
Thanks for pointing this out.
As an aside, google.dev’s IP is not routable; see https://stackoverflow.com/a/25665936
Ryan Monday, September 18, 2017 at 05:54 -
Use .test or gtfo.
Aaron Cooper Monday, January 8, 2018 at 05:38 -
I do, on my test environment. Because that is it’s purpose. The same reason why I used .dev for development, not testing.
Each to their own, but I find it a bit absurd to pass off the removal of a domain that has a phonetic link to the environment’s intention to use another one that has an entirely different intention.
Dave Sunday, February 11, 2018 at 16:17 -
^^^ this exactly. We use .test for our virtualised test environments, for which .test is served by internal DNS and is routable within the company, so this isn’t an option for local dev.
John McCormack Monday, September 18, 2017 at 12:57 -
Yeah… I’m using Chrome less and less, using Firefox more and more.
Loïc Lavoie Monday, September 18, 2017 at 19:08 -
You guys should remove the recommandation for .localhost as an alternative. Chrome and Safari force loopback on the locahost domain and any subdomain in it.
This means that any adresses ending with .localhost will force redirect to 127.0.0.1 without querying DNS’s or your hosts file.
https://webmasters.stackexchange.com/questions/88636/why-does-chrome-resolve-websitename-localhost-as-localhost
Guillaume Sunday, September 24, 2017 at 19:11 -
+1. I had this problem several month ago, and it’s totally blocking if you are using a virtual machine like Vagrant, with a specific local IP.
I understand frustration from (not all) people who commented here, but using .dev could prevent you from scaling your project towards a centralized multisite with a variation on TLD. As Hanno said, IMHO best practice seems to be using https://dev.domain.tld for local dev of a live site, http://localhost%5B:PORT%5D/%5Bdomain/%5D or some specific IP redirected locally for a quick project development / code testing.
Dave Sunday, February 11, 2018 at 16:18 -
How exactly would this prevent scaling?
Zardoz Tuesday, September 19, 2017 at 10:13 -
1. Drop Chrome, in fact drop evil google generally
2. use local.yourdomain.com with a *yourdomain.com cert for testing
ak Wednesday, December 13, 2017 at 16:50 -
And I hope google will eventually learn the lesson; Don’t break the web!
Ashley Sheridan Tuesday, September 19, 2017 at 23:08 -
To be fair, the .dev TLD was made available a long time ago, so any developer using it locally should have expected problems eventually. I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.
Braeden Friday, January 5, 2018 at 22:01 -
There shouldn’t be a problem with using any .tdn if you mod your host file because that will redirect any existing domain name to your local machine. The problem here is that chrome is forcing HTTPS for a local site. I have code in place to detect whether I am on development or production so that .dev doesn’t use the same settings on production. But chrome forces https for .dev when it shouldn’t.
Gareth Wednesday, February 7, 2018 at 14:33 -
Correct. You should be able to use google.com or anything else as a local domain if you choose to do so via your hosts configuration file.
rox0r Tuesday, February 27, 2018 at 20:04 -
> I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.
You don’t have control over the public DNS system. Which is why people run their own local DNS system that is a complete fork. There is no standard against running your own private DNS system. This treats those domains special when there is nothing special about them. If anything, chrome/firefox is assuming that the user is using the public DNS system.
vjanzen Wednesday, September 20, 2017 at 21:19 -
The IP 127.0.53.53 is a name collision entry.
tim Thursday, September 21, 2017 at 00:07 -
I used use .local then found out about the clash with Bonjour. Then I switched to .server for my local servers (so far so good) and .dev for my local development (oh dear). But fortunately I use a dnsmasq server and can switch it out for something else. I name things as their full production domain plus .dev on the end, and that’s been fine for now. Many of the web apps I work with require a single domain name hard coded into a config file (such is life) so there will be one-time pain of updating those. I would support an official .localhost if it didn’t introduce untold security holes.
Fuck You Thursday, September 21, 2017 at 04:16 -
f**king stupid google, go f**king eat s**t. We are using .dev for develop domain in our company, and all of a suddent we can’t access our dev sites anymore, WTF. Bulls**t!!!!
Anh Tran Thursday, September 21, 2017 at 04:43 -
Don’t know what Google is up to, but this is not a smart step. Affecting all the developers in the world with a simple commit. A millions of working hours will be wasted.
ian Hobbs Friday, September 22, 2017 at 00:01 -
interesting…. I just always used .site domain
Google Stupid Friday, September 22, 2017 at 09:04 -
Google is evil. If they do that, let’s use https://blisk.io
wut Friday, September 22, 2017 at 15:49 -
… Blisk is build on Chromium…
Matthias Monday, September 25, 2017 at 17:07 -
People. Just use the domain that’s actually reserved for testing. .test. You can, of course, easily get valid certificates for that. They just need to be in the local certificate store. Laravel Valet does that autimatically. Others do, too.
Aaron Cooper Monday, January 8, 2018 at 05:39 -
People aren’t complaining about test environments. They’re complaining about development environments.
Burak Thursday, November 9, 2017 at 23:04 -
Wtf, I wasted my days to find the issue. I was about to clean reinstall my Mac.
foogle Thursday, December 7, 2017 at 12:04 -
Yes WTF Google is trying to do? What a pain they are causing to developers like myself, I think they trying to monopolize and we’r like their puppets that they can control go to hell google.
Sierk Bornemann Thursday, December 7, 2017 at 15:49 -
RFC 2606 (June 1999): Reserved Top Level DNS Names
https://tools.ietf.org/html/rfc2606
[quote]
[…]
2. TLDs for Testing, & Documentation Examples
There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.
For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
“.test” is recommended for use in testing of current or new DNS
related code.
“.example” is recommended for use in documentation or as examples.
“.invalid” is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
The “.localhost” TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
[…]
[/quote]
Dave Sunday, February 11, 2018 at 16:28 -
“For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. ”
The purpose of this document was to reserve TLDs for use in documentation and test code for DNS server implementations.
Note also that when developing enhancements for existing production systems I am often very deliberately ensuring that “local attempts to reference the real data in these zones could be thwarted by the local test versions” and my browser should not be trying to “help” me by playing Big Brother. Its almost as bad as the incessant insertion of www. before anything I type in the address bar.
Dani Thursday, December 7, 2017 at 18:06 -
That decision is bullshit! Time for another browser.
Aykut Friday, December 8, 2017 at 17:28 -
Well other browsers planning to use it soon.
Dan Friday, December 8, 2017 at 04:22 -
Thank you for posting this article. I just wasted 3 hours of my life on this. Would have been nice if Google had just posted a simple error message. If not for your article, I don’t know what I would have done!
katwekibs Monday, March 26, 2018 at 09:51 -
Missing the point. Google has nothing to do with this. Google might own the .dev tld, but like any other tlds, i could still be able to bypass the server lookup using my host file or local dns service.
The problem is Firefox now renders our host file useless by not querying it first. This is a BS decision from Firefox them selves not google.
Marat Friday, December 8, 2017 at 09:22 -
Thanks for info. Wasted hours on this
mostafa Saturday, December 9, 2017 at 11:26 -
shit …
shiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit
:|
Adam Patterson Sunday, December 10, 2017 at 23:09 -
I don’t really get why chrome forces the HTTPS though? Personally, I have to set my prefered domain. I handle the redirection of HTTP to HTTPS.
And Google owning the .dev TLD is kinda shitty to force this change on people, Weather you think its good in the long run. I would bet that no one owns a .dev and you probably won’t.
Changedev Tuesday, December 12, 2017 at 02:43 -
I opened a incognito window and still got redirected to https. Thought something broke something. Thank you for saving my day trying to figure this out. I can now spend the rest of the day changing all my wordpress installs. Yay, such fun.
angry guy Tuesday, December 12, 2017 at 09:04 -
Chrome tech leads and managers are idiots
Tesh Tuesday, December 12, 2017 at 14:18 -
Time to use Firefox again like back in the old days!
Gareth Wednesday, February 7, 2018 at 14:34 -
The same thing happens in Firefox as of today
Chrome TD Tuesday, December 12, 2017 at 20:24 -
What happened to not being evil Google??
Mister Ree Friday, January 12, 2018 at 04:48 -
Part of being evil is deceiving people into thinking you’re not evil.
Svetlana Wednesday, December 13, 2017 at 11:29 -
Saved my day. Thanks! I wonder why still no word from Google, would have been nice to hear something like “Hey webdevs, ditch your .dev-s, because now we rule your domain”… But no, of course, all of a sudden I just can’t reach my dev ground any more, as it’s all httpsssssed
Tyler Reed Thursday, December 14, 2017 at 17:41 -
That, and some people have a “dev” environment AND a “test” environment. One of the projects I’ve worked one needed 6 environments (for coding, testing, acceptance, staging, etc.). Making our local sites end in “.test” would confuse our staff into thinking that our development environment is our test environment.
Cysioland Wednesday, December 13, 2017 at 19:52 -
They urge people to use domains like .test, but also disallow these in their OAuth redirects.
Tamas Amon Thursday, December 14, 2017 at 00:22 -
I made:
valet domain test
And now I using every directory with .test and not .dev
Not a nice feature form google chrome
ChromeDeveloper Thursday, December 14, 2017 at 12:30 -
I have no words
Klaus Donnert Thursday, December 14, 2017 at 14:52 -
I just switched to Firefox. Problem solved.
Alex Thursday, December 14, 2017 at 16:36 -
I hate other browsers but i going to use safari or something.
Alexander Thursday, December 14, 2017 at 18:11 -
Wasted half a day trying to reach my dev site… I use it with https but it still doesn’t work.
Although you said that “Have that self-signed certificate added to your local trust store (you can’t dismiss self-signed certificates with HSTS, they need to be ‘trusted’ by your computer)”
I’ve added certificate to my windows machine but it still doesn’t work.
Could someone, please, explain what is the correct way to add certificate “local trust store” so that I can continue to use .dev site via https?
Ed Thursday, December 21, 2017 at 02:00 -
Are you calling Google idiots? or telling us to Google the word “idiots”? or calling us idiots because we’re not Googling?
Noname Friday, December 15, 2017 at 15:41 -
Google idiots!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
google idiot Friday, December 15, 2017 at 17:16 -
down grade google chrome fuck you google idiots
Alex Friday, December 15, 2017 at 17:32 -
Hey, Google, why only .dev & .foo? Go on, redirect all domains to https…
Couple of idiots in Google tell me what TDLs I should use for develop.
google idiot Friday, December 15, 2017 at 17:47 -
google chrome 60.0.3112.113, this good work :D
Mark Friday, December 15, 2017 at 17:48 -
Agree with you. Today they tell us how to name local domains and tomorrow how to wipe our ass
VIPStephan Wednesday, March 14, 2018 at 22:01 -
I’m now using “loc” as local development domain. But I’m not 100% set on that yet. Perhaps change it to “dvl” if you want it closer to the original?
Bruce Klein Friday, December 15, 2017 at 23:54 -
Thank you for publishing this explanation.
TobiVino Saturday, December 16, 2017 at 06:34 -
Same thing goes with .app prefix , damn chrome
Boris van Katwijk Friday, March 23, 2018 at 15:32 -
When using docker-compose services, beware of naming your services dev, app or foo. These may cause the same redirects e.g. when using selenium to access your services.
Digital Apps Sunday, December 17, 2017 at 11:52 -
so glad i found this article, half a day wasted on configuring my apache. google, its a bad idea.
Masa Sunday, December 17, 2017 at 15:39 -
Crome team literally hate developers. :( They have made impossible configure self-verify certificates and now this. All this no other reason other than being ash. What it’s them what I do my computer?
There is cost LetsEncrypt certificates you haw to pay domain.
Kevin Monday, December 18, 2017 at 12:11 -
Very thankful for this article, wasted several hours on this…
Emanuele Ciriachi Monday, December 18, 2017 at 13:09 -
Well this is some annoying nonsense right here. Goodbye Chrome, welcome Brave.
toddz Monday, December 18, 2017 at 21:31 -
Is there a Chrome Extension that can fix this – to allow “.dev” domains locally? I want to stay in Chrome because I like its Dev Tools, and changing the “.dev” to “.test” in all my databases would be a huge pain.
Jalcide Wednesday, December 20, 2017 at 19:01 -
Ugh. This is so irksome. Of course Google’s update rolled out at the exact moment I updated my VM, sending me on a red herring goose chase.
I refuse to use .test, on principle. I’m not TESTing, I’m DEVeloping.
The .dev gTLD shouldn’t even be a thing. Clearly, it should be reserved for developing.
What alternative (not .test nor .localhost) are people using?
Thomas Wood Wednesday, December 20, 2017 at 19:48 -
*.localhost (properly referred to as “localhost.”) is already defined in RFC6761 https://tools.ietf.org/html/rfc6761 to always resolve to the local loopback interface. The linked proposal RFC forces DNS resolvers to not use the domain search list if they encounter “localhost” as the final portion of the requested address, and to assume that “localhost.” (the localhost TLD) was intended.
Google are planning to open *.dev for public registration in early 2018: https://www.registry.google/
FML Thursday, December 21, 2017 at 04:02 -
WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.
Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”
FML Thursday, December 21, 2017 at 04:04 -
WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.
Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”
UPDATE: corrected email address, delete my other post if you wish.
Jean-Michel Garnier Wednesday, January 10, 2018 at 14:40 -
Would you mind sharing a documentation link which explains this constraint ?
Thanks for your comment :)
Charan Thursday, December 21, 2017 at 13:21 -
As Developer i will continue to use *.dev for Developemnt setup , what ever the google has to do with .dev domain let them do still localhost is all ours to lay rules !
jmandawg Thursday, December 21, 2017 at 13:25 -
Unfortunately there is a bug, this also redirects http://dev/ (where dev is an entry in my hosts file) to https which is not *.dev
Ali Saturday, December 23, 2017 at 23:09 -
I’m using dnsmasq and nginx to test my codes locally, I use self signed certificates for all .dev domains too.
The problem is that Chrome shows following error everytime I want to access my local domains:
Your connection is not private
Attackers might be trying to steal your information from *****.dev (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
No more information.
Thank you google for ruining my development environment for the whole week :|
Chris Monday, January 1, 2018 at 02:02 -
site.localhost doesn’t work in latest Chrome either but site.test works
Dave Wednesday, January 3, 2018 at 12:11 -
Ow goody. Google better bring out a patch where you’re able to easily switch this off… within the development inspect window or something. Cause developing != testing. I’ve got .dev .test and .preprod urls that I use in my workflow and this move sh*ts all over that. Happy new year!
Gazsi Friday, January 5, 2018 at 19:22 -
say goodby to chrome, welcome to new firefox
steve Thursday, January 18, 2018 at 15:22 -
Oh well, that explains the last few hours of frustration.
I cant just ditch chrome, the dev tools are better and I use it in automated testing as well.
I guess i am going to have to sort out a self-signed cert solution – anyone have any pointers?
Jean Monday, January 22, 2018 at 19:54 -
Im also very upset with all these decisions. SOFTWARES SHOULD EXECUTE WHAT YOU ASK AND NOT THE OPPOSITE. If I want to go to blabla.dev, I don’t want to go to https://blabla.dev. This is the first principle of software UX. I definitely think that google developers should go back to school !!
Renan Saturday, January 27, 2018 at 04:40 -
What about using dev as a subdomain like dev.yoursite.com? I’ve changed my own hosts using prefix dev.* and fixed the issue.
Berg Wednesday, January 31, 2018 at 22:45 -
Yeah you’re right. I also think this should be a good workaround.
Here’s my setup:
dev.my-app.com
test.my-app.com
stage.my-app.com
Ben McIlwain Friday, February 2, 2018 at 03:52 -
Using real domains or subdomains that you own is actually the ideal, recommended way to set up testing/development sites. It solves the problem of name collisions and some services not allowing not-real domain likes (like *.test ones).
So it’s definitely not a work-around, it’s a best practice!
Dave Sunday, February 11, 2018 at 16:49 -
Only for your limited naive web-dev use case. Not all internetworked applications are the public face of your organisation. For example, one of my systems is a massively distributed swarm of microservices using unqualified service names for instance resolution through DNS. In this case a single public facing application with a single web UI hostname is backed by a few dozen private app hostnames that should only ever resolve within their datacentre. So we stage our apps through .dev, .test, .uat, and then to private domains named for their datacentre.
It used to be simple to test parts of this system through the browser in development – now its broken and “just change to .test” isn’t an option. With Google about to publicly sell .dev domains the problem is about to move beyond the browser. All in all allowing the .dev TLD to be registered in the first place was a major fuckup by ICANN. .dev and .test were chosen by me many years ago (long before Larry or Sergei had even thought of Google) because the ISI naming rules of the time meant it could never become a TLD. So what you consider a poor practice today WAS best practice until the goal posts moved.
Javier Saturday, February 10, 2018 at 13:19 -
Three days I can’t use FF for development, many thanks.
jalmos Tuesday, February 13, 2018 at 08:34 -
Thanks for the notice. Haven’t run into any noticeable problems yet, thank His Noodly Appendage.
Must grant this does encourage some good practices, forcing people to use a cert from the start, as my experience tells, can sometimes prevent disaster in projects with first-time/unknown/multiple/platform-or-language-specific admins/devs. It’s also honestly ‘best practice’ to have dev traffic encrypted, even if it’s already happening at the netsec level (shit, it would be best to be hardwired to a gapped vlan, if you have anything worth stealing).
That said, I have a lot of work on a .xxx.dev, and so do plenty of others. All this makes me think is ‘how much work will I have to put in to resurrect FF or will it be quicker to do all the renaming work, given how bad FF is now?)”
This just feels like a ‘because f(*$ you, that’s why’ situation. My dev urls are all second subdomains, with 15-char random sequences at the top. What do I need SSL for until I’m ready for it? What moron was making easily-guessed dev sites for any parent site worth being included in a bot scanner list?
Of course the big S is better in general, but to apply like this? That’s not acting in anyone’s best interest. That’s just throwing your weight around. Excepting morons putting up data worth stealing, no one will benefit from this in any meaningful way.
After saying all that, I mist admit that, apparently, this will help a lot of morons. So, not a total loss in terms of ‘do the right thing’ (still violates ‘don’t be evil’ in my estimation).
Google, you’ve done enough to help them already.
Sobri Kamal Wednesday, February 28, 2018 at 08:21 -
There you go right there straight up stupid decision from google..Im surprise such decision were made in google..Dictionary have to update their definition of ‘Google’ to -> Dumbass..How come they want to dictate what kind of domain i should for my local development? Plain stupid
Adnan Friday, March 2, 2018 at 07:43 -
I have created vhost on my local machine. using wamp. I don’t think so this is a good approach.
Daniel Thursday, March 15, 2018 at 15:03 -
You can disable the preloadlist at firefox.
Just change network.stricttransportsecurity.preloadlist to false.
Now your .dev-Domain will work again with http :-)
Ben McIlwain Thursday, March 15, 2018 at 16:30 -
Don’t do that. It disables enforcement of security on tens of thousands of sites, including big sites that you likely use every day, like gmail.com, github.com, wikipedia.org, twitter.com, facebook.com, maybe your bank, etc.
This “remedy” is like ripping your front door off because you locked yourself out once.
Leo Monday, March 19, 2018 at 04:31 -
Using a separate *Testing* profile can avoid this danger.
And disable HSTS doesn’t mean disable HTTPS, it’s only a pre-load list.
Leo Monday, March 19, 2018 at 04:23 -
Thanks very much.
I’m just looking for a solution for this issue.
Ergo Tuesday, April 3, 2018 at 11:47 -
Thankfully, Serverpress the developers of DesktopServer (an excellent local server package for WP dev, which I find invaluable) have a free solution to this for both their clients and the general dev community. It’s based on their own domain: dev.cc. This link explains all: https://docs.serverpress.com/article/232-how-to-change-top-level-domain-dev-extension-google-chrome-users
Dave Wednesday, March 21, 2018 at 15:40 -
Thank you for this post!!! I’ve been having trouble with Chrome and Firefox so I had to switch to Edge. Fortunately, for once, Microsoft doesn’t fall in line with every body else and I was able to keep my development going. But what a pain in the a** this is!!!
tutoref Friday, March 23, 2018 at 21:00 -
Is it legal if someone make an extension that reverses that behavior ?
tutoref Friday, March 23, 2018 at 23:52 -
Ok I found a solution for Firefox but not for Chrome.
Check the solution here : https://tutoref.com/how-to-prevent-firefox-and-chrome-from-forcing-dev-and-foo-domains-to-use-https/
Note : For firefox you can do some alternatives.
Francois Tuesday, May 22, 2018 at 09:12 -
network.stricttransportsecurity.preloadlist on firefox is working fine, thanks!
John Sunday, April 1, 2018 at 19:45 -
Fucking idiots at Mozilla breaking “localhost” development just because someone bought a domain on the internet!
How morons can their developers be?
I lost two days of work trying to fix this crap.
The only good fix is to downgrade Firefox to an older not so stupid version.
Ergo Wednesday, April 4, 2018 at 10:51 -
Thankfully, Serverpress – the developers of DesktopServer (an excellent local server package for WP dev) have released a free solution to this for both their clients and the general dev community. It’s based on their own domain: dev.cc. Read about it here:
https://docs.serverpress.com/article/232-how-to-change-top-level-domain-dev-extension-google-chrome-users
Annie Wednesday, April 11, 2018 at 18:36 -
THANK YOU – like so many others, I lost half a day trying to ‘fix’ this (when Firefox started pulling the same crap Chrome began months ago with all my dev sites) – and another half day switching them all over to .test, and undoing the various attempts I made yesterday to overcome the problem without knowing its origin. A little warning in the browsers would have saved a sh!tload of wasted time!
Rick Umali Tuesday, May 1, 2018 at 14:49 -
Mattias: Thank you for posting this. I was so confused why my ‘.dev’ site loaded properly in lynx and curl, but not Firefox or Chrome. Danke!
Max Friday, May 4, 2018 at 09:25 -
MAAAN, I was trying to figure out what was the problem with my local dev env… You know what, I am really tired of google doing different crap just because they can. I already changed my default search to duckduckgo, now i am seriously considering switching to Firefox from chrome. Hard to find the replacement for youtube unfortunately.
Gokuu Tuesday, July 24, 2018 at 15:00 -
Gooood lord, google what the f***ing hell. Took us whole day to figure out what the hell is happening.
Tnx much for article.