Skip to Content

Avoid .dev Domains for Test Environments

Unless you're armed with TLS certificates.

Published on

"http://*.dev" with the "http" part struck through, surrounded by random characters.

You might think that the .dev TLD is excellent for staging and development environments. It has it in its name, after all. But by default, it comes with increased security and automatically enabled HTTP Strict-Transport-Security (HSTS)(opens in new tab), as Google has stated on get.dev(opens in new tab):

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.

What this means is that it's impossible to open an HTTP connection to a .dev domain through a browser. When you might want that? Certainly while testing and setting up your project.

Example

Let's say you have an Elastic Beanstalk application in AWS and you add a CNAME record pointing to your .dev domain. If you open that domain in the browser, the request will probably time out and you'd think it's a DNS issue. But running:

curl -XGET -I http://mydomain.dev

…would normally return a response with status code 200.

That's because curl is not a browser and has no concept of HSTS. It doesn't parse the Strict-Transport-Security header as anything special. The browser, however, doesn't even make an attempt to establish an HTTP connection and check if that header exists. Everything ending in .dev is part of the aforementioned HSTS preload list. When the browser sees anything ending in .dev, it directly performs an internal 307 redirect on its own to the HTTPS version. If your load balancer in Elastic Beanstalk has no listener on port 443 - you get a timeout.

Other TLDs

Maybe you'll think that as an alternative, you could use obscure TLDs, such as .xyz. Unfortunately, those may come with their own peculiarities. If you're testing out emails, you might get poor deliverability, as explained in an article by spot.com(opens in new tab):

Even though we weren’t even sending emails from .xyz domains, simply including occasional links with URLs ending in .xyz caused very poor deliverability for our customers. We quickly course-corrected and switched over to .net and .com domains and the situation improved.

You might also get poor SMS deliverability:

One surprising side effect of having a .xyz domain is that the mere inclusion of .xyz inside of a text message will result in a silent delivery failure for many providers.

…and firewall issues:

When Googling about, it is common to come across webmasters who are seeking advice(opens in new tab) on how to block the entire domain. Even if your application is strictly obeying the best etiquette possible, simply being associated with a .xyz domain is enough to become entirely inaccessible.

Conclusion

Avoid .dev domains in non-production environments, unless enforced HTTPS is the very thing you want to test. Also avoid weird and obscure TLDs, such as .xyz, or at least do your own research. The best approach might be to go with the tried and tested .com and .net TLDs.