Using HTTPS DNS records

If you've come here hoping to learn what a HTTPS record does, my post: A simple guide to the HTTPS DNS record, is a good place to start. Otherwise read on.

When I started researching my post about the current state of HTTPS DNS records, I regularly found either domain owners or software implementers were confused regarding common usage scenarios for HTTPS records and whether they would work or indeed if they should work.

So I think describing some use cases and how a software client should behave when presented with those use cases, may help readers better design their DNS or client software implementation.

Expected Pain Points

The RFC has several scenarios in the document, but I think they skirt around some of the points of friction that many domain owners may have when trying to make use of the HTTPS record. For example for ServiceMode the RFC describes CDN outsourcing behaviour, but shows only examples where the TargetName is a subdomain of the origin, which is unlikely to be common. So I've had a crack at scenarios which I think are likely. As a result, some of these are speculative based on expected, but not yet observed, behaviour of clients. I will update these scenarios as real world usage emerges.

Use Cases

All use cases assume correctly behaving software. Correct behaviour in this case is interpreted as following the RFC insofar as a supported capability is documented. However, as I've noted in the companion post to this one, correct behaviour is certainly not common at the time of writing.

I'm not bothering with older protocols in my examples. While support is possible and envisaged in the RFC, I wrote about how silly it would be to deploy a cutting edge technology for consumption by a client that also needs to be very recent, simply to use an out of date transport protocol.

Combining use cases

I'll start off describing very simple use cases. These will describe the basic flow of HTTPS queries and responses. As I get to the more complex examples, you'll notice that these will combine the simple use cases, sometimes in long chains. This combining of use cases is expected by the RFC.

Use Case 1: Single Endpoint, same hostname

This is the simplest scenario. We have a single endpoint¹ that supports http/1.1 and http/2.

Our DNS configuration

1$ORIGIN test.ninja.
2; Apex HTTPS record.
3@        IN      HTTPS       1 . alpn="h2"; The target will be an apex A or AAAA record.
4                                          ; HTTP/1.1 is also supported in this scenario
5                                          ; because there is no 'no-default-alpn' present.
6; A and AAAA records for my web servers
7@        IN      A         198.51.100.100
8@        IN      AAAA      2001:DB8::100

Let's see what happens when a client queries for https://test.ninja

1. The client asks for a HTTPS record of any mode
2. The client receives a Service Mode response with protocol and Endpoint connection details.
3. Since the TargetName² of . was supplied to the client in step 2 it is interpreted by the client as the owner label (test.ninja in this case). The client queries for A/AAAA records for the derived endpoint address
4. Client receives IP addresses
5. Client uses protocol details from step 2 to connect to IP addresses from step 4, using the origin³ header of: https://test.ninja.

If you've looked at my post discussing implementing HTTPS records you'll know that we can add some minor changes to this use case to explicitly state no http/1.1 support:

@ IN HTTPS 1 . no-default-alpn alpn="h2"

This won't materially impact the flow described above.

Use Case 2: Apex Alias to Target with no HTTPS support

This is likely to be a very common use case while the transition to HTTPS remains in its early stages. We want to alias DNS queries to the apex of the domain to another domain which is managed by a webhosting/CDN provider. Our provider does not support HTTPS records in their domain.

Our DNS Configuration

1$ORIGIN test.ninja.
2; Apex HTTPS record.
3@        IN      HTTPS   0   mycdn.example.com.

A very simple representation of our CDN provider's DNS

1$ORIGIN example.com
2; the hostname given to CDN customers
3mycdn   IN  CNAME   pool1.example.com.
4pool1    IN  A   203.0.113.1 ; Likely to be a dynamically allocated IP

The diagram below shows what happens when a domain has an Alias mode HTTPS record and the CDN provider doesn't support HTTPS

1. The client asks for a HTTPS record of any mode
2. The client receives an Alias Mode response with a TargetName of mycdn.example.com. No other details can be supplied from an Alias mode response. The origin name is not modified as a result of this answer.
3. The client restarts its resolution process with another request for a HTTPS record of any mode.
4. The client is told that no such record exists.
5. The client attempts to resolve mycdn.example.com the old fashioned way, by sending A and AAAA queries for the name.
6. The client received a CNAME response with a new endpoint to resolve.
7. The client queries for the A and AAAA records for the new endpoint from step 6.
8. The client received an IPv4 record in response
9. The client attempts to connect to the origin hostname (https://test.ninja), using the IP address received in step 8. No protocol upgrade or ECH possible prior to initial connection to this host.

While there are quite a few steps in the above process, the HTTPS resolution flow ends at step 4 when the client is informed that there is no HTTPS record for mycdn.example.com. From that point onwards, the DNS resolution behaviour is the same as it would be for any address resolution process. Bearing in mind that step 5 commences the address resolution of a name discovered through the HTTPS response in step 2. It is possible to have multiple Alias Mode entries, but not any Service mode entries for the same label. If there are multiple Alias mode records, the client will pick one at random at step 3.

Use Case 3: Multiple Service Mode Records, subdomain endpoints

This use case adds a little complexity to use case 1 by offering a client multiple endpoints to connect to. The intent of this scenario is to allow a client to select an endpoint that supports the protocols it prefers. One hopes that the client always prefers the highest security option, but this is not enforced via resolution of HTTPS records.

Service Mode allows for a rudimentary load balancing effect when multiple records are returned containing service parameters that the client supports. The real world utility of this kind of load balancing is questionable, but it is important to understand client behaviour.

The DNS configuration for multiple Service Mode records:

 1$ORIGIN test.ninja.
 2; Apex HTTPS record.
 3@        IN      HTTPS       2 rand0.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
 4@        IN      HTTPS       2 rand1.test.ninja. alpn="h2" ; Randomly selected by clients that don't support http3 and QUIC
 5@        IN      HTTPS       1 quic-web.test.ninja. no-default-alpn alpn="h3" ; Preferred by clients that support http3 and QUIC
 6; A and AAAA records for my web servers
 7rand0   IN      A         198.51.100.110
 8rand0   IN      AAAA      2001:DB8::110
 9rand1   IN      A         198.51.100.111
10rand1   IN      AAAA      2001:DB8::111
11quic-web    IN  A         198.51.100.200
12quic-web    IN  AAAA      2001:DB8::200

Let's see what happens when a client that doesnt support QUIC tries to connect to https://test.ninja:

1. The client asks for a HTTPS record of any mode
2. The client receives several Service Mode responses. There is 1 endpoint which supports QUIC and no other protocol. 2 other endpoints both support http1.1 and http2 connections.
3. Since the client does not support QUIC this endpoint is immediately discarded. Service Priority is not considered yet. The remaining endpoints support the same protocols which are also supported by the client. Since they are the same priority the client randomly chooses rand1.test.ninja and requests the IP address for the endpoint. Note that the client does not send an HTTPS query for the endpoint it just selected.
4. Client receives IP addresses
5. Client uses protocol details from step 2 to connect to IP addresses from step 4, using the origin header of: https://test.ninja.

If the client in the above use case supported QUIC then the quic-web endpoint would have been selected due to its higher (lower number) priority.

Use Case 4: Service Mode Record, non-subdomain endpoint (anti pattern)

This use case is not explicitly covered in the RFC, but is often inferred by people implementing HTTPS records in their domain. In this use case we can have a similar configuration to either use case 1 or use case 3 however we use an endpoint with a domain that is not a subdomain of the origin domain.

I consider this usage an anti-pattern since it can result in the wrong Service Params⁴ being supplied to the client. This use case would typically be fulfilled with one or more Alias mode entries. I am describing it here because it is possible to configure and an operator may not observe an immediate indicator of failure.

Our DNS configuration

1$ORIGIN test.ninja.
2@        IN      HTTPS       1  mycdn.example.com. no-default-alpn alpn="h3"; 

Our CDN provider's DNS configuration

1$ORIGIN example.com
2; the hostname given to CDN customers
3mycdn   IN  CNAME   pool1.example.com.
4pool1    IN  A   203.0.113.1 ; Likely to be a dynamically allocated IP

Let's see what happens when a client tries to connect to https://test.ninja. Our client supports QUIC (http3), but our CDN provider doesn't.

1. The client asks for a HTTPS record of any mode
2. The client receives a Service Mode response with protocol and Endpoint connection details.
3. The client queries for A/AAAA records for the endpoint address. A HTTPS query is not sent for the received endpoint.
4. Client receives CNAME
5. Client queries for A/AAAA records for label it received in step 4
6. Client receives IP addresses
7. Client uses protocol details from step 2 to attempt a connection to IP addresses from step 5, using the origin header of: https://test.ninja. Since the CDN provider doesn't support QUIC This will not work.

If a client receives an Alias mode response, it will first send an HTTPS query for the received TargetName. However with a Service mode response, the client will store the received Service Params and then attempt to resolve the received endpoint using A/AAAA queries. If the CDN provider does not support the protocols the client was provided via Service Params, then the connection attempt would fail.

The domain operator for test.ninja could determine which protocols the CDN provider supports and they could then match that with the appropriate Service Params. But this would be a fragile architecture heavily reliant on manual configuration and luck.

I've seen this configuration in cases where domain operators were attempting to work around the poorly implemented HTTPS support of browsers. Since Alias mode has the least functional support, domain operators have attempted to use Service mode records to achieve the same outcome.

Don't do this. Having read this section, it should come as no surprise to you that I recommend against this configuration.

Use Case 5: Apex Alias to Target with HTTPS support

I expect this to be amongst the most common configurations once there is broad support amongst browsers for Alias mode responses. From the perspective of the domain owner of test.ninja, there is little difference with use case 2. However with this use case our CDN provider supports answering HTTPS queries for their domain.

The CDN provider can use a DNS configuration similar to either use case 1 or use case 3. I would speculate that the flexibility provided by having multiple endpoints with differing protocols would be attractive to a CDN and so expect this to be the most likely configuration. The choice of DNS configuration taken by the CDN provider will not impact the domain owner of test.ninja and will be transparent to clients. It is this ability to separate operational choices that is the key benefit of Alias mode HTTPS records.

Our DNS Configuration

1$ORIGIN test.ninja.
2; Apex HTTPS record.
3@           IN      HTTPS   0   mycdn.example.com.

A very simple representation of our CDN provider's DNS

1$ORIGIN example.com
2; the hostname given to CDN customers
3mycdn       IN      HTTPS   1  web-pool1 no-default-alpn alpn="h2,h3"; 
4web-pool1   IN      CNAME   pool1.example.com.
5pool1       IN      A       203.0.113.1 ; 

A client attempts to connect to https://test.ninja. The client supports http2.

1. The client asks for a HTTPS record of any mode
2. The client receives an Alias Mode response with a TargetName of mycdn.example.com. No other details can be supplied from an Alias mode response. The origin header is not modified as a result of this answer.
3. The client restarts its resolution process with another request for the HTTPS record of any mode for mycdn.example.com.
4. The client receives a Service mode response with an endpoint of web-pool1.example.com indicating support for http2 and http3.
5. Since the response from step 4 was a Service mode record, the client does not send an HTTPS query for web-pool1.example.com. Instead it attempts to resolve the endpoint address with A/AAAA queries.
6. The client receives a CNAME response with a new endpoint to resolve.
7. The client queries for the A and AAAA records for the new endpoint from step 6.
8. The client received an IPv4 record in response
9. The client attempts to connect to the origin hostname (https://test.ninja), using the IP address received in step 8. Since the client supports http2 only, it will attempt to connect to the IP address using http2.

The CDN provider could alter its DNS configuration to include more Service mode records either for load balancing purposes or to provide endpoints with different protocol support. These updates would not require any changes to the test.ninja domain.

Just as it is possible to chain CNAMES, Alias mode HTTPS records could also be chained. For example the CDN provider may have aliased mycdn.example.com to another domain entirely. Client software is expected to place an upper limit on these chains.

Use Case 6: Multiple Apex Alias records (anti pattern)

The RFC states that there should be only one Alias mode record present for a record set. However it also states that if there are multiple records present, the client should pick one at random. So some DNS server platforms may not allow multiple Alias mode records, but some might. Since the described client behaviour is less equivocal than the server behaviour a possible use case emerges.

I consider this an anti pattern since the RFC is quite explicit in stating this should not happen. However since the RFC has allowed for it to happen nevertheless, I think it is worth documenting.

Our DNS Configuration.

1$ORIGIN test.ninja.
2; Assuming our DNS server allows this configuration
3@           IN      HTTPS   0   mycdn.example.com.
4@           IN      HTTPS   0   cdn2.provider.example.

We have 2 CDN providers. As we saw in use case 2 and use case 5 the CDN providers' DNS configuration is entirely independent of the test.ninja DNS configuration.

1$ORIGIN example.com
2; CDN 1. HTTPS record supported
3mycdn       IN      HTTPS   1  web-pool1 no-default-alpn alpn="h2,h3"; 
4web-pool1   IN      CNAME   pool1.example.com.
5pool1       IN      A       203.0.113.1

1$ORIGIN provider.example
2; CDN 2. No HTTPS record support
3cdn2        IN      CNAME   host1.provider.example
4host1       IN      A       192.0.2.10

The only unique element of this use case to those above, is the random selection of an Alias mode record. Once selected, the flow of queries and answers would mirror the use cases above.

1. If the client selects @ IN HTTPS 0 mycdn.example.com. then the flow for use case 5 is applicable.
2. If the client selects @ IN HTTPS 0 cdn2.provider.example. then the flow for use case 2 is applicable.

The likelihood of this design working reliably is low in my opinion. Since it will be clients that select the initial record to use at random, this won't be an opportunity to manage traffic on behalf of the domain operator. Perhaps those organisations which have embraced the multi-cloud design strategy to ludicrous levels will find this an attractive solution? Bear in mind that DNS server implementations may not allow multiple Alias mode entries for the same record set, thus preventing this configuration and limiting your ability to move between DNS operators.

Don't do this. There's no compelling benefit and a very high chance of interoperability issues.

References

The HTTPS DNS record RFC: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

The draft for the Service Param (SvcParam) for Encrypted Client Hello:Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings

The draft for Encrypted Client Hello: TLS Encrypted Client Hello

My Other Posts on HTTPS DNS records

A simple guide to the HTTPS DNS record

The below post was written alongside this one.

The current state of HTTPS DNS record support

Terminology

The SVCB RFC has a brief discussion of the terminology it uses. In addition to that write up, I've included some clarifications in my own words below.