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.

Update

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.

"zone file showing A records at the apex, which work and cname at the apex, which doesnt work"
What works and what I want

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:

More info
  • 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.
More info
  • 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.

NAMETTLINprioritytargetparameters

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 AliasMode
  • 1-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.
Warning

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 info

    ECH 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.