The .dev TLD Is Here, and It's HTTPS-Only by Design

After years in Google's registry, the .dev top-level domain is opening to the public. Early access starts today, and general availability follows on February 28. Developers have wanted these names for a long time, so expect a rush.

.dev comes with a property that catches people off guard: the entire TLD is on the HSTS preload list. Every .dev domain is HTTPS-only in every major browser from the moment it exists. There's no "we'll add the certificate later" phase. Whether or not you're planning to buy one, it's a good time to understand HSTS preloading, because it's becoming a common way to raise the web's security baseline.

What HSTS does

HTTP Strict Transport Security is a response header that tells a browser never to talk to this site over plain HTTP again. Once a browser has seen it, every future request to that domain is upgraded to HTTPS before it leaves the machine, with no insecure redirect hop for a network attacker to intercept.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

The pieces:

• max-age: how long, in seconds, the browser should remember the rule. A year is the usual minimum for a serious deployment.
• includeSubDomains: apply the rule to every subdomain, not just the host that served the header.
• preload: a signal that you consent to being built into browsers (see below).

HSTS closes the classic downgrade window. Without it, a user who types yoursite.com into the address bar makes a plain-HTTP request first, and anyone on the network path, such as coffee-shop Wi-Fi or a compromised router, can intercept that request before your redirect to HTTPS happens.

Preloading: HSTS before the first visit

The header has one weakness: the browser has to see it once before it protects anything, so the very first visit still goes out over plain HTTP.

Preloading closes that gap. Browsers ship with a hardcoded list of domains, maintained through hstspreload.org and used by Chrome, Firefox, Safari and Edge, that are HTTPS-only out of the box. A preloaded domain never gets a plain-HTTP request from a modern browser, including the first one from a brand-new device.

You can check any domain's status, and submit your own, at hstspreload.org. The requirements are strict:

• A valid certificate.
• A redirect from HTTP to HTTPS on the same host, if you listen on port 80 at all.
• All subdomains served over HTTPS, including that forgotten intranet. record.
• The header itself, with a max-age of at least one year, includeSubDomains and the preload directive.

The commitment it implies

The subdomain requirement is where preloading bites. Submitting your domain is close to irreversible: removal from the list is possible but takes months to reach users through browser releases. Once you're in:

• Every subdomain must serve HTTPS, permanently. That includes the old vendor-hosted page on a CNAME, the mail host with a self-signed certificate, and whatever dev.internal.yoursite.com is.
• A certificate mistake becomes a hard outage. Without HSTS, an expired certificate shows users a warning they can (unwisely) click through. With HSTS, the browser shows an error page with no bypass. An expired certificate on a preloaded domain makes the site unreachable.

That isn't an argument against preloading. It's an argument for treating it as a commitment you monitor. Preload when your whole domain is genuinely HTTPS-clean, and put monitoring on certificate expiry the same day, because the failure mode changes from a warning to a wall.

An entire TLD on the list

Google's approach here is clever: instead of individual domains, it added whole TLDs to the preload list. .app came first, opening to the public in May 2018 as the first TLD where HTTPS was a technical requirement rather than best practice. .page followed late last year, and now .dev joins them.

So if you buy example.dev, it's preloaded before you've configured a single DNS record, and you can't serve it over plain HTTP to any modern browser. The decision was made at the registry. For a new site in 2019, that's how it should be.

The Chrome 63 backstory

Many developers already know .dev is HTTPS-only, for a painful reason. For years .dev was a popular fake TLD for local environments: myproject.dev in /etc/hosts, or set up automatically by tools like the old Pow server on macOS. Google owned the TLD, but it wasn't live, so nothing broke.

Then Chrome 63 shipped in December 2017 with .dev on the preload list, and a lot of local setups stopped working overnight. Chrome refused to load http://myproject.dev, with no way to click through. The fix was to move local environments to .test or .localhost, the names actually reserved for that purpose.

The lesson generalizes: TLDs you don't own can start resolving, and start carrying policy, at any time. Use reserved names for local work, and treat public DNS as someone else's namespace.

Launching HTTPS-only from day one

Whether or not you buy a .dev domain, its constraint is worth adopting voluntarily: build as if plain HTTP doesn't exist.

• Automate certificates from the start. Let's Encrypt makes them free, and ACME clients handle renewal. A 90-day certificate on autopilot beats a two-year certificate on a calendar reminder.
• Test the strict path. Confirm your site works with HTTPS only: no mixed content, no hardcoded http:// asset URLs in templates, cookies marked Secure.
• Check the header is reaching browsers:

curl -sI https://example.dev | grep -i strict-transport-security
# Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Monitor it as the hard dependency it is. On an HSTS-preloaded domain, your certificate is your uptime.

Where CompleteStatus fits

On an HTTPS-only domain, certificate trouble isn't a warning users might click past; it's a full outage. CompleteStatus monitors SSL certificate expiry and validity alongside uptime checks in one dashboard, and alerts you weeks before an expiry date rather than the morning after. If you're registering a .dev domain this month, create a free account and add a monitor the day you point DNS at it.