What are SVCB DNS records?
Let's start with, what are DNS records?
In the DNS, information is stored in Resource Records (RRs) of which there are many types (RRTYPEs), depending on the kind of information that needs to be stored.
For example, address records (A for IPv4 and AAAA for IPv6) can hold a single IP address each. These are used by clients to find the addresses of network endpoints.
NS (NameServer) records hold a single Fully-Qualified Domain Name (FQDN) of a DNS server. These are used by resolvers (most usually DNS servers) to find the nameservers responsible for a particular zone.
Some RRTYPEs are more complex, in that they can store several pieces of information. For example, Mail eXchange (MX) records hold both a single FQDN of a mail server AND a priority value associated with that mail server, so that if there are multiple mail servers available for a zone the mail client can choose which one(s) to use based on the priority.
New RRTYPEs are added to the DNS sometimes as new protocols are introduced to the world, if existing RRTYPEs can't hold the information necessary for operation of these new protocols.
Two new RRTYPEs were proposed in 2022/23: SVCB and HTTPS. SVCB stands for SerViCe Binding and HTTPS stands for HyperText Transfer Protocol Secure.
We'll look at SVCB first:
What does it look like and what is it for?
SVCB and HTTPS records were initially proposed here and are now standardised here. The purpose of SVCB is to provide a flexible way to map services to resources. Let's look at its record structure.
| Type | TTL | Class | element_1 | element_2 | element_3 |
|---|---|---|---|---|---|
| 64 | [<integer>] | [IN] | SvcPriority | TargetName | [SvcParams] |
SvcPriority is a two octet field (16 bits) for indicating the priorty of one SVCB record relative to another of the same name, with lower values being preferred; much like the MX and SRV record types. It can be interpreted as a cost - lower cost is better. The value zero is special and indicates AliasMode: more about modes soon.
TargetName is the FQDN of either the alias target (for AliasMode) or the alternative endpoint (for ServiceMode). More about these terms later.
SvcParams are optional, depending on the mode used. If included they are a whitespace-separated list, with each SvcParam consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.
AliasMode
AliasMode is indicated by a priority value of zero and works a bit like the CNAME RR, in that it is used to translate (or alias) one FQDN - the owner name - to a different FQDN - the target name. There are, though, some important differences between this usage of SVCB and CNAME records.
| CNAME | SVCB |
|---|---|
| Cannot be used at the zone apex | Can be used at the zone apex |
| Matches any QTYPE | Matches only the QTYPE |
| Has no concept of service type | Is service aware: similar to the SRV RR type |
| Only one record can exist per owner | Multiple records can exist per owner |
Taking these in order:
- One of the major (perceived) limitations of the CNAME record type is that it cannot be used to redirect or alias the zone itself. This follows from the fact that CNAMEs are a sort of wildcard, or last resort record, in that they match any QTYPE. The consequence of this is that there MUST not be any other records in a zone with the same owner name as a CNAME record. e.g. this is illegal:
www IN A 1.2.3.4
www IN CNAME www.another.domain.
Since a zone MUST contain exactly one SOA record and at least one NS record, both of which have as their owner names the name of the zone itself, there cannot also exist a CNAME record whose name is the same as the zone name.
- The SVCB record type will only be matched by its own QTYPE - unlike CNAME, which will match any QTYPE - so it does not act as a wildcard in the same way that CNAME does and is not, therefore, a general purpose CNAME replacement. Clients must be SVCB-aware and make queries for this type. The consequence of this is that SVCB records may co-exist with any other record types that share the same name, including SOA and NS, which therefore allows for aliasing of the zone.
- SVCB records may contain extra information prepended to the owner name that can be queried and used by a service-aware client when requesting details about how to access a particular type of service, rather than simply where an endpoint lives. In this regard the SVCB type builds and extends on the concepts introduced with the SRV record type.
- Since a CNAME record cannot exist with any other record of the same name, this includes another CNAME record. e.g. this is illegal:
www IN CNAME server1.example.com.
www IN CNAME server2.example.net.
This means that the CNAME record can only provide a single, 1-to-1 translation. The SVCB record type has no such restriction, so it is possible to provide multiple destinations all offering the same service. For example, this is legal:
example.com. IN SVCB mydomain.org.
example.com. IN SVCB mydomain.net.
example.com. IN SVCB mydomain.com.
How does it work in practice?
A service provider is authoritative for the zone example.com and wishes to make available a new service that uses a specific handler (foo) and is accessed on a non-standard port (8080). The service will actually be given its own name and will be hosted in a different zone - example.net - so its native FQDN will be foosvc.example.net.
A suitable SVCB record to make this work would be:
_8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.
The SVCB-aware client will make an SVCB DNS query for _8080._foo.example.com, which will be translated to foosvc.example.net. This is then resolved and provides the client with the IP address of the server on which the service runs.
The labels starting with an underscore character are known as prefix labels. Their use at the beginning of the set of labels is to designate scoping. That is, to limit the scope of the service required at a given name.
In this case _8080 is the layer-4 port to use when accessing this service and _foo is the handler to use. Thus it would be possible to publish many different services, each using different port numbers and/or handlers, all at the same domain - example.com.
ServiceMode
ServiceMode is designated by priority values greater than zero (1-65535). In this mode, TargetName specifies an alternate endpoint FQDN for the service in question and SvcParams specify the connection parameters for it. Together they define a protocol scheme.
Since these parameters are specific to a particular protocol scheme there is no standard use of the SvcParams field. However, each protocol scheme must define a consistent set of parameters that it expects to be used for the scheme to work. Clients making ServiceMode SVCB queries for a particular protocol scheme are expected to understand and be able to make use of the parameters returned in the answer. Any parameters they don't understand MUST be ignored.
Here is an example ServiceMode SVCB DNS record:
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (alpn="bar" port="8004" ech="..." )
Note that the list of service paramaters is contained in parenthesis to cause them to be treated as a single item.
alpn stands for Application-Layer Protocol Negotiation and is one of the service parameters defined initially for use with SVCB. It is used to list the available application layer protocols supported by this endpoint for this service. "bar" is just a fictitious example.
port defines the layer-4 port on which the endpoint will be listening for this service - 8004 in this case. It is also one of the service parameters defined initially for use with SVCB.
ech stands for Encrypted Client Hello and is also one of the service parameters defined initially for use with SVCB. In this example, the ellipsis is a placeholder for what, in reality, would be an ECHConfigList, as defined in section 4 of the Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings draft.
What are HTTPS DNS records?
The purpose of the HTTPS record type is to define service mappings specific to the HTTPS protocol. It shares the same syntax (described below) as the SVCB record type and is a specific use case of the more generalised SVCB.
What do they look like?
HTTPS was also proposed here. This is its record structure:
| Type | TTL | Class | element_1 | element_2 | element_3 |
|---|---|---|---|---|---|
| 65 | [<integer>] | [IN] | SvcPriority | TargetName | [SvcParams] |
If the service being referred to is HTTPS, running on the standard port number (443) then there is no need for prefix labels as these are the default. If not, then prefix labels may be used, as with SVCB records.
Here are a couple of examples of both:
AliasMode
example.com. 3600 IN HTTPS 0 foosvc.example.net.
This record is at the origin of the zone example.com and shows that an HTTPS service is available for that name using the default handler (HTTPS) and default port (443). The SvcPriority value is zero, indicating Alias mode, the same as with the SVCB record type.
This is the simplest form of an HTTPS record, which can be viewed as an alternative to the CNAME record, without its restrictions, but limited to clients that understand this type and that want a web service.
ServiceMode
_8443._https.example.com. IN HTTPS 1 alt3.example. (alpn=h2,h3)
_8443._https.example.com. IN HTTPS 2 alt4.example. (alpn=h2)
These records indicate that the web service accessible at example.com uses the HTTPS protocol and runs on a non-standard port; 8443. This is indicated by the prefixes prepended to the owner name.
They also show that the primary instance of the service - indicated by priority 1 - runs on a server or servers known by the FQDN alt3.example, which support both the HTTP/2 ad QUIC transport methods.
A backup service is also defined - indicated by priority 2 - which runs on a server or servers known by the FQDN alt4.example that support the HTTP/2 transport method, but not QUIC.