Simple HTTPS Records
In This Article
The new DNS record, HTTPS, is now supported by both clients and servers. So I thought it might be useful to discuss why and how you can use it. I'm going to focus on the most common uses with some simple explanations. If you'd like to dive deeper into this new record, I'll include some links at the end of this article.
The draft specification has now become RFC 9460. Some links in this post have been updated to reflect the change of status of the document. I intend to revisit this topic in an upcoming blog post.
Why?
Have you ever needed to have a CNAME at the apex of your domain name? This configuration is commonly desired when you wish to redirect the top of your domain (eg test.ninja) to another organisation or service provider. The correct way to do this in DNS was to add A or AAAA records. However many providers would prefer that you use a CNAME to a service that they can add and remove hosts from, without having to ask you to update your domain's configuration.
If you hosted your own DNS and tried to add a CNAME as I have above, your software would have told you it was a malformed configuration. If you used a DNS hoster, they may have supported it, but under the hood there would have been a complicated set of A records and custom web forwarding. That is, regardless of how much software developers and DNS hosters tried to hide it from you, a CNAME at the apex of a domain has always been a complicated and occasionally fragile configuration. Complicated because of the non DNS services needed to maintain the illusion that the domain was being forwarded and fragile because other DNS systems (your consumers for example) may not interoperate with the resulting configuration. This problem isn't new, but the solution has been a long time in coming.
As you'll see with some of the use cases I'll discuss later, redirecting the top level of your domain to another organisation is not the only reason to use the HTTPS DNS record.
What?
We know there's a new DNS record and it's going to at least fullfil a use case where the top level of my domain will be forwarded. But if I don't need to send the consumer to another organisation's systems, I can still use the HTTPS record to supply useful information to modern clients. Very roughly that's the two modes of the HTTPS record:
- AliasMode: Delegates operational control of the record. This is our apex CNAME scenario above. Of course, you are not limited to the apex, you can use this to delegate control of a sub domain.
- ServiceMode: Where a set of key/value pairs are used to describe configuration information for an endpoint.
If the explanation isn't really making sense yet, don't worry, in the Example section we'll see some practical use cases.
How?
Using the HTTPS record initially just requires modifying the contents of your DNS zone file. However in some cases you'll also want to make additional changes to your web server in order to get the most out of the new record.
Let's talk about the record format. What can you put in the HTTPS record?
HTTPS Resource Record Format
The format of the HTTPS record conforms to the structure below.
NAME TTL IN
priority target parameters
Name
As with all DNS records you have the name or owner label of the record in the left most field.
TTL
There's no specific guidance for TTLs for HTTPS records. However, you'll notice that the nature of these records means that they are unlikely to rapidly change, meaning that you can have larger TTLs, reducing the load or costs for your DNS host, while improving the experience for consumers since their resolvers can cache for longer.
Priority
Required
Integer between 0-65535. Lower values mean higher preference (similar to MX records).
0
priority denotes AliasMode1-65535
apply to ServiceMode records.- It is possible to have multiple records of the same priority. In such cases, the client will pick one at random to use. Having multiple records with
0
priority, is acceptable. However that kind of configuration is unlikely to appear in most common designs.
While researching configuration for HTTPS, I've come across some articles that do not include the priority field for AliasMode records. This may represent a valid record from an earlier draft version of the svcb-https standard. My reading of the most recent document is that this field is required to be present for AliasMode records.
Target
Required
The end point for the service. Must be a valid domain name or .
(dot).
If the value is .
then:
- if the record is an alias, it is considered disabled by the client and ignored.
- if the record describes the service endpoint a
.
in the target field means that the owner is the endpoint. For example, the record below indicates that the endpoint will be webstore.test.ninja
1webstore.test.ninja. 3600 IN HTTPS 1 . alpn="h2"
In all other cases, the target field will contain the host which is the endpoint. If you have multiple HTTPS records for the same source address, it is possible to have the same or different target values.
Parameters
Optional
These are the key value pairs which will be sent to the client explaining the configuration of the host in the target field.
-
alpn: This field includes the short form identifier for Application Layer Protocol Negotiation Protocol Identifiers. However in practical terms there's only 2 values that will be useful:
- h2: represents http/2 over TLS. Most ordinary websites will fall into this category
- h3: represents http/3. This is HTTP over the new QUIC protocol. You'll find this supported by the more cutting edge providers.
- http/1.1: represents http/1.1. There is no shorter identifier. This is the default ALPN value for the HTTPS record and therefore does not need to be included as a parameter.
-
no-default-alpn: Tells clients that the target does not support the default ALPN value (HTTP 1.1). Therefore when this parameter is present, the alpn parameter must also be present, so that the client has some valid protocols to choose from.
-
port: integer 0 - 65535. The port at which the service can be reached on the target. TCP or UDP is implied via the transport.
-
ech: base64 encoded ECHConfigList. Do not use escape sequences.
More infoECH stands for Encrypted Client Hello and is the more secure alternative to SNI used by web servers today. The ECHConfigList is the list of ECH configuration types the server supports. Software to support this is not commonly available today, so I won't cover it any further in this article.
-
ipv4hint and ipv6hint: A comma separated list of IPs for the appropriate family. Do not use escape sequences. These addresses are used initially to establish a connection to the target host. However the client is expected to resolve the target host address via A or AAAA records for all subsequent connections.
Examples
So we've learned a little about why the record exists and how it is implemented, now let's start using it..
For all the examples below I'll be configuring the DNS for the test.ninja
domain. My CDN provider uses the example.com
domain for all their endpoints. Check out the Resources section for full copies of all the examples.
The test.ninja
zone file before HTTPS:
1@ IN SOA a.nic.test.ninja. dnsadmin.test.ninja. (
2 1000 ; Serial
3 28800 ; Refresh
4 14400 ; Retry
5 604800 ; Expire - 1 week
6 86400 ) ; Minimum
7; An apex A record for when people type in 'test.ninja' (no www)
8 IN A 192.0.2.1 ; web forwarding service to mycdn.example.com
9 IN A 192.0.2.2 ; web forwarding service to mycdn.example.com
10; For when people type in 'www.test.ninja'
11www IN CNAME mycdn.example.com.
12
13; An apex CNAME is what I really need for when people type in 'test.ninja' (no www)
14; IN CNAME mycdn.example.com.
AliasMode
The configuration of AliasMode is quite straight forward. Ensure that the priority is set to "0". The target is the CDN provider's target host. You'll notice that this is the same as the host used in the original test.ninja zone file.
1; An apex HTTPS record for when people type in 'test.ninja' (no www)
2 IN HTTPS 0 mycdn.example.com.
3; For when people type in 'www.test.ninja'
4www IN HTTPS 0 mycdn.example.com.
ServiceMode
Simple Configuration
The simplest service mode example is a single target, for which we supply some additional configuration parameters. In the example below I have apex A
and AAAA
records for my web servers. These web servers are configured to answer for both "test.ninja" and "www.test.ninja". The HTTPS entry in the zone for www
explicitly targets the test.ninja
host name, whereas the HTTPS entry for the apex uses the .
target as shorthand to state that the client should use the A or AAAA record for the test.ninja
host as the target. I've specified that this target host accepts http/2 over TLS, in addition to the implied http/1.1 support.
The configuration below could represent a single server or several servers sitting behind a single load-balancer endpoint.
1; An apex HTTPS record for when people type in 'test.ninja' (no www)
2 IN HTTPS 1 . alpn="h2" ; The target will be an apex A or AAAA record.
3 ; HTTP/1.1 is also supported because there is no
4 ; `no-default-alpn` present.
5; For when people type in 'www.test.ninja'
6www IN HTTPS 1 test.ninja. alpn="h2"
7; A and AAAA records for my web servers
8 IN A 198.51.100.100
9 IN AAAA 2001:DB8::100
Preferred Order
I might have several endpoints. I can suggest that clients use my preferred order of priority using the configuration below. As with mail server (MX record) priorities, never assume that this order will be strictly followed.
1; An apex HTTPS record for when people type in 'test.ninja' (no www)
2 IN HTTPS 1 . alpn="h2" ; The target will be an apex A or AAAA record.
3 IN HTTPS 2 web2.test.ninja. alpn="h2" ; Use my backup server if the primary is unavailable.
4; For when people type in 'www.test.ninja'
5www IN HTTPS 1 test.ninja. alpn="h2"
6www IN HTTPS 2 web2.test.ninja. alpn="h2" ; Use my backup server if the primary is unavailable.
7; A and AAAA records for my web servers
8 IN A 198.51.100.100
9 IN AAAA 2001:DB8::100
10web2 IN A 198.51.100.102 ; My backup web server
11web2 IN AAAA 2001:DB8::102 ; My backup web server
Multiple Choice
If there are multiple HTTPS records of the same priority then the client should choose one at random. While you could use this as a really simple type of load balancing, that kind of design is simply unnecessary with today's technology. However you can use this method to give a client a choice of the endpoint that will provide it the protocols it prefers.
A realistic example is where a new end point has been created to support HTTP3 and QUIC and is made available to clients. We want all clients that support these protocols to choose this new endpoint. Clients that only support older protocols will continue to use the older web endpoints. If an HTTPS record contains no protocols that the client supports, the client will ignore it. Therefore clients which do not support QUIC will choose at random one of either rand0
or rand1
.
1; An apex HTTPS record for when people type in 'test.ninja' (no www)
2 IN HTTPS 2 rand0.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
3 IN HTTPS 2 rand1.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
4 IN HTTPS 1 quic-web.test.ninja. no-default-alpn alpn="h3" ; Preferred by clients that support http3 and QUIC
5; For when people type in 'www.test.ninja'
6www IN HTTPS 2 rand0.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
7www IN HTTPS 2 rand1.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
8www IN HTTPS 1 quic-web.test.ninja. no-default-alpn alpn="h3" ; Preferred by clients that support http3 and QUIC
Transition Example
If you have a web forward at your zone apex today in order to facilitate redirecting to a CDN, then consider the example below. Since not all your clients will support HTTPS in the short term, you'll need to retain your existing records, while offering more modern clients the new AliasMode entries.
1; An apex A record for when people type in 'test.ninja' (no www)
2 IN A 192.0.2.1 ; For clients that do not support HTTPS records
3 IN A 192.0.2.2 ; For clients that do not support HTTPS records
4 IN HTTPS 0 mycdn.example.com. ; For clients that support HTTPS records
5; For when people type in 'www.test.ninja'
6www IN CNAME mycdn.example.com. ; For clients that do not support HTTPS records
7www IN HTTPS 0 mycdn.example.com. ; For clients that support HTTPS records
ServiceMode records will be ignored by older clients, so you'll have to ensure that any endpoints a client receives when resolving a host, supports the broadest possible range of protocols. Using the multiple choice example from above, let's ensure that our older clients will still resolve a host that supports protocols that they can connect with.
1; An apex HTTPS record for when people type in 'test.ninja' (no www)
2 IN HTTPS 2 rand0.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
3 IN HTTPS 2 rand1.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
4 IN HTTPS 1 quic-web.test.ninja. no-default-alpn alpn="h3" ; Preferred by clients that support http3 and QUIC
5; For when people type in 'www.test.ninja'
6www IN HTTPS 2 rand0.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
7www IN HTTPS 2 rand1.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
8www IN HTTPS 1 quic-web.test.ninja. no-default-alpn alpn="h3" ; Preferred by clients that support http3 and QUIC
9; A and AAAA records for my web servers
10 IN A 198.51.100.110
11 IN AAAA 2001:DB8::110
12 IN A 198.51.100.111
13 IN AAAA 2001:DB8::111
14www IN A 198.51.100.110
15www IN AAAA 2001:DB8::110
16www IN A 198.51.100.111
17www IN AAAA 2001:DB8::111
18rand0 IN A 198.51.100.110
19rand0 IN AAAA 2001:DB8::110
20rand1 IN A 198.51.100.111
21rand1 IN AAAA 2001:DB8::111
22quic-web IN A 198.51.100.200
23quic-web IN AAAA 2001:DB8::200
In the example above, we've added apex and www
A
and AAA
records which HTTPS RR unaware clients will use. These are the addresses of our older endpoints rand0
and rand1
which will support the protocols our older clients will need.
Browser and client support
- IOS and MacOS will attempt to resolve a HTTPS record for all connections using http or https or those which use ports 80 or 443.
- Firefox has supported the record since version 92.
- Chrome 88 introduced support for the record if the client also had a DoH (DNS over HTTPS) endpoint configured.
These Records are Secure Right?
It should go without saying, but I'll say it anyway, the security benefits of this record are only genuine if you DNSSec sign your zone. This is true of nearly every modern security feature in DNS since around 2008. Otherwise you are transmitting information to clients that they have no way of validating.
The information you can pass along to the client via the new HTTPS record is of particular benefit if you are using modern protocols such as Encrypted Client Hello and HTTP3 over QUIC. So it follows that getting the most out of this record, you should improve the security posture of your endpoints. If you're using a CDN, you should ensure that your provider has a good security posture.
The other risk you should be aware of is combining records of different security levels. If you do have endpoints with lesser security capabilities, these should be have a lower priority (ie, a larger number in the priority field) than those endpoints which have better security options for the client.
SVCB Records
The HTTPS Record is actually an implementation of a Service Binding compatible (SVCB) Resource Record. There may be other new records in the future that are also Service Binding compatible. I'll leave some resources at the end of this article if you want to explore that rabbit hole.
Resources
You can find all the example zone files here.
The IANA registry for all alpn values can be found here. Note that not all ALPN values will make sense or even work with the HTTPS record.
The Service Binding (SVCB) protocol document can be found here
NGINX supports HTTP3 and QUIC, with some effort on your part.