Google .dev domain strangely redirects to https
.dev
domains are HTTPS only. It isn't a redirect. It is HSTS preload.
HSTS is a technology that lets domains declare that they are HTTPS only. It is meant to mitigate against protocol downgrade attacks. The first time you visit a site that wants to use HSTS, you get a header that prevents you from ever visiting that domain on HTTP.
The HSTS preload list is built into web browsers so that the browser knows a site is HTTPS only, even before the first visit. If a site is on the HSTS preload list, it will never be able to be accessed via HTTP in that browser, only via HTTPS.
Google has put the entire .dev
top level domain on the HSTS preload list. That means that no .dev
domain will ever be able run as an HTTP site.
When you registered your .dev
domain, the Google registry told you this on the front page under the "Security benifits" section:
Get built in security
Your security is our priority. The .dev top-level domain is included on the HSTS preload list, making HTTPS required on all connections to .dev websites and pages without needing individual HSTS registration or configuration. Security is built in.
Currently only Firefox and Chrome support this HSTS preload. If you want to be able to test your site before you have HTTPS set up, you could use a different browser. You also might be able to modify your browser settings to disable HSTS.
Because of the HSTS preload, you will need to run your .dev
domain on an HTTPS server so that users can access it.
Related videos on Youtube
Johnny
Updated on September 18, 2022Comments
-
Johnny over 1 year
I bought a .dev domain today @ domains.google. I also set up a dedicated nginx web server to which the .dev domain points (A records).
Very strangely, I can't access my nginx welcome page using my
example.dev
domain, because for some weird reason I'm redirected tohttps://example.dev
which then fails (no connection to my http web server can be established). However, any other domain pointing to this new server works correctly. Likeexample.com
just works. I didn't configure ANYTHING about nginx, just installed it (the demo config does the job). Obviously enough, this has something to do with Google as the registrar. OK - so I shall contact the Google support, right? Yes. I did that, however, they told me this was something I needed to handle on my side and always referring to 'contact your web host' (which isn't too much of an advice since I'm the host).I tried everything in the Google console, but I can't get it to work. The Google support was very, very disappointing and I'm now hoping to see some resolutions on this problem.
-
Johnny about 5 yearsThat's it. I must have missed this piece of info, and the support team wouldn't remind me of this fact again (even though I think it's pretty obvious I was missing exactly this info).
-
Stephen Ostermiller about 5 yearsYes, support should have been able to tell you this.
-
Niet the Dark Absol about 5 yearsThat blog post you linked mentions "A lot of (web) developers use a local .dev TLD for their own development." - this is literally the first time I've ever heard of this practice o_O
-
Kevin about 5 years@Chris:
*.test
is probably safe enough for most reasonable use cases. People (particularly Microsoft) used to use.local
, but then Avahi and Bonjour annexed it, and now it's mostly only used with mDNS. -
ave about 5 years@Johnny btw, you might be interested in Let's Encrypt: letsencrypt.org
-
Johnny about 5 years@Ave thanks, I already had my .dev domain set up my SSL with LE. It worked perfectly.
-
Alex Jone about 5 yearsAnother Google-created TLD,
.app
, is also an HTTPS-only namespace. Beware. -
superlinkx about 5 yearsFor dev domains, the two that are reserved are *.test and *.localhost. They are fully reserved, so will never be taken over as real TLDs. *.localhost is actually really nice if you're doing localhost testing, as you can use multiple services like you would with other TLDs, and it still maps to 127.0.0.1. *.test is meant for any dns related stuff, so if you need to map to virtual machine IPs or something, that's your go-to. Lately I've been a big fan of *.localhost with docker containers, since I map the reverse proxy to 127.0.0.1 anyway. Requires no local dns or /etc/hosts shenanigans.
-
Sandeep Bhaskar about 5 years@AlexJone all new Google TLDs will be on the preload list...
-
Sandeep Bhaskar about 5 yearsRFC 2606 is the authoritative source on reserved TLDs. The list is: .test .invalid .example .localhost ; for other reasons note also that .local is a special case.
-
Sandeep Bhaskar about 5 years@Johnny Google registry mandates all of its registrars to clearly display a note during registration to explain that any domain bought needs a "SSL certificate" (sic), which hints at the fact that at least for the web, HTTPS is mandatory.
-
Johnny about 5 years@AlexJone yes, however, I had a domain setup @ namecheap.com with an '.app' domain without HSTS preload.
-
user1686 about 5 years@superlinkx: What systems map *.localhost to an address by default?
-
user1686 about 5 years(IANA recently reserved .home.arpa for "home LAN" usage, so I would suggest that as an option for local dev servers.)