Taking advantage of your TLD to further improve web security with HSTS

Home > Observatory and resources > Expert papers > Taking advantage of your TLD to further improve web security with HSTS

07/08/2025

Some TLDs (top level domains) are reserved for a single organisation. These are often referred to as .brand, .corp or sometimes even as “specification 13 TLDs”, from the relevant addendum to the ICANN Registry Agreement. French examples include .sncf and .total. Being reserved to a single organisation, they can allow actions that would not be reasonable in the case of a domain open to the public. For example, use can be made of the HSTS technique to force all names under a particular domain to use secure HTTP connections. Let’s take a look at the details.

Security of HTTP and HTTPS

As you know, there are two variants of the Hypertext Transfer Protocol (HTTP), one in clear and as such vulnerable to all sorts of attacks, and the other, Hypertext Transfer Protocol Secure, (HTTPS) encrypted and authenticated. This second variant is highly recommended, particularly for any website that is even only slightly sensitive. One limitation of HTTPS however is, or rather was, that the domain name administrator could not easily force HTTPS to be used in all its sub-domains. While the administrator had control of example.com itself, there was always the risk that a department .example.com still only had HTTP without the “S” and as such without the security provided by encoding.

For a TLD open to the public, such as .fr or .org, there can of course be no question of forcing all the websites in its sub-domain to do anything, even in the name of security. But closed TLDs do offer this possibility.

HSTS

HSTS (HTTP Strict Transport Security) is a security technique allowing the domain administrator to impose the use of HTTPS on all its sub-domains. Note that it is not based on the DNS (Domain Name System) but is carried out solely in HTTP. How does it work? The HTTP server, when connected to, indicates that this domain – and, if so specified, all its sub-domains – have only HTTPS servers, as opposed to the older HTTP. The HTTP client used (e.g. a web browser) will memorise this information and in future will connect only in HTTPS mode, flatly refusing to use HTTP without the “S”, even if the user so requests.

A little more technical information? Here is the HTTP response header field sent by a server using HSTS:

Strict-Transport-Security: max-age=2592000

This HTTP response header field is the instruction that the browser will follow. And if we wish this instruction to extend to sub-domains?

Strict-Transport-Security: max-age=2592000; includeSubDomains

The sub-domains of the domain where the HTTP client recovered this instruction will now be covered by it. Of course, the manager of the HTTP server must not add the instruction includeSubDomains if the sub-domains have been delegated to other organisations, which might have their own security policies.

HSTS was standardised in RFC 6797 in 2012 and is now widely adopted in online apps.

But how can I do it in the DNS?

OK, so this is the Afnic blog and you expect me to talk about the DNS, rather than the web. But HSTS, which is a HTTP security technique, can only be configured using HTTP. So please don’t try to put this information in the DNS, as in the case of SPF (Sender Policy Framework, to authenticate email) or DANE (DNS-based Authentication of Named Entities, to authenticate a certificate without a certificate authority).

If you have your own TLD and you’re in a position to lay down a security policy for all its sub-domains, you’re going to have to configure a HTTP server on the TLD. If your TLD is .example, you’ll need a server to respond to https://example/, by sending the STS field as above.

And that’s where the trouble starts. There are several problems with the web address in the foregoing paragraph but I will refer to just one: ICANN does not allow^[1] TLDs under contract with it to place any kind of domain name record at the top level of the DNS. In order for https://example/ to work, one needs to be able to place a type A (IPv4 address), or type AAAA (IPv6 address) record or the most recent type of HTTPS on .example. But this is prohibited by ICANN. There is however a solution.

Registering in browsers

One of the limitations of HSTS is that you need a HTTP connection in order to receive the HSTS instruction. From the security point of view this is far from ideal. It would be better if the strict “no HTTP without encryption” policy were applied from the outset. There is a way of dealing with this, and which, at the same time, solves the problem of not being allowed to place the records that HTTP needs at the head of the TLD.

This solution is pre-loading. The HTTP client (typically a web browser) is configured with a list of domains (not necessarily TLDs) that are considered as being always in HSTS mode. The main web browsers generally use the same list ^[2], which is managed by the team at Chromium, the free version of Google’s web browser.

To have your .brand or .corp added to this list, you have to apply online. Caution: this can take several weeks to process. It will take less time if your domain is on the Public Suffix List, which in principle is the case with all TLDs.

To see this list, technophiles must download the Chromium source code and look for the file net/http/transport_security_state_static.json.

Conclusion

One of the advantages of having your own TLD is the ability to configure HSTS to improve the security of all your sub-domains. Go for it!

Notes:

[1] See Base Registry Agreement, exhibit A “Approved Services”: “The above language effectively does not allow, among other things, the inclusion of DNS resource records that would enable a dotless domain.

(Back to the text)

[2] To see this list, technophiles must download the Chromium source code and look for the file net/http/transport_security_state_static.json.

(Back to the text)