DNS is a key component of modern computing, a phone book for IP addresses. It is distinct from other protocols in the application stack. Because it is queried early in the request by a client, DNS is well suited to relay application-specific information back to a client as early as possible. This additional data can be used by the client to improve the security and performance of the underlying application before other protocols like HTTP, TLS, and Simple Mail Transfer Protocol (SMTP) take over for the application.

Amazon Route 53 supports many different resource records, detailed in the Route 53 Developer Guide. These records allow DNS servers to answer client queries with additional data beyond just an IP address. DNS as we know it today has undergone many extensions and changes since it was established as a standard. Adding new resource record types is a common enhancement that is made to DNS standards.

Today, Amazon Web Services (AWS) announces that Amazon Route 53 now supports four additional DNS resource record types: Service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records. These record types allow additional data to be supplied through DNS responses to improve application security and performance.

In this post, we break down each record type and discuss what these records are designed to accomplish and common challenges we see where they could be useful.

SVCB and HTTPS records

SVCB and HTTPS records allow application owners to bind endpoint-specific information into the DNS reply in the form of key-value parameters. While SVCB records can be used for any service, irrespective of protocol, HTTPS records are specific for use with the HTTP protocol. HTTPS records can specify parameters of a web service such HTTP protocol version, nonstandard TCP or UDP ports, TLS security requirements, and more. Without these records, the client would need to send a standard request to the server and rely on the server to reply with additional information. Then, the client could make another request on a new protocol or to a new server. This meant additional latency and potentially less secure communication because the initial session was negotiated between the client and server.

Both SVCB and HTTPS records support two modes: AliasMode, which aliases a DNS name to another DNS name, and ServiceMode, which allows passing a number of different parameters that are required to connect to a service. The format of the SVCB and HTTPS records are similar. The main difference is that the SVCB record name includes the port and protocol, while HTTPS records do not. The resource record value comprises three fields: Priority, Target Name, and Service Parameters, each separated by spaces. The following example of SVCB record structure shows the different parameters.

_port._protocol.fully-qualified-domain-name TTL IN SVCB [Priority] [Target Name] [Service Parameters]

• The [Priority] field indicates what mode the SVCB or HTTPS record is in. A value of 0 denotes AliasMode, while any other value denotes ServiceMode. It is more common to see an SVCB or HTTPS record in AliasMode used with an apex record, while ServiceMode is used with any record type. (NOTE: While the [Priority] field supports a value from 0–65535 as defined in the RFC specification, Amazon Route 53 supports a [Priority] value from 0–32767).
• The [Target Name] field points to the destination resource that needs to be reached.
• The [Service Parameters] field, which is only used in ServiceMode, allows you to specify a list of key-value pairs that contain endpoint-specific information about [Target Name]. Common parameters that can be specified include TLS Application-Layer Protocol Negotitation (ALPN) prompt message, Port number, Encrypted Client Hello (ECH) configuration information for the endpoint, or even IP hints. The Route 53 Developer Guide has more details on different supported values.

The functionality of AliasMode may be familiar to Route 53 administrators already using Route 53 alias records, which can be used at the top node of a DNS namespace. However, while Route 53 alias records allow aliasing to only supported AWS resources, AliasMode in SVCB or HTTPS records supports aliasing to any DNS record.

The following shows an HTTPS record for example.com, which is the apex record for the domain configured in AliasMode, and two HTTPS records for www.example.com configured in ServiceMode:

example.com 300 IN HTTPS 0 www.example.com 
www.example.com 300 IN HTTPS 1 host1.example.com alpn="h3,h2" ipv4hint="192.0.2.34, 198.51.100.103" ipv6hint="2001:db8:8f9::c8e1" 
www.example.com 300 IN HTTPS 2 host2.example.com alpn="h2,http/1.1" ech="123abc456efh789ijk012mno"

If we break down both HTTPS ServiceMode records for www.example.com even further, we see www.example.com has two alternate endpoints to reach:

• The first endpoint, host1.example.com, should be more preferred since it has a lower [Priority] value, and supports both HTTP/3 (preferred) and HTTP/2 connections. In addition, the record also include fallback IPv4 and IPv6 addresses that the client can use to connect, if unable to get an A or AAAA record..
• The second endpoint, host2.example.com, is less preferred since it has a higher [Priority] value, and supports HTTP/2 and HTTP/1.1 connections. The base64-encoded version of the public key for the endpoint is provided, so the client can establish a TLS session with an encrypted Client Hello message to the endpoint.

A primary use case of the HTTPS record is better support for HTTP/3 clients and servers. Figure 1 shows the sequence of requests between a client and server to establish a HTTP/3 connection if HTTPS records were not used:

Figure 1: HTTP3 connection establishment without HTTPS record.

At a high level, the entire flow can be summarized as:

• Steps 1–2: The client sends a DNS query for the A or AAAA record of the endpoint to connect to and gets a corresponding IPv4 or IPv6 address in the DNS response.
• Steps 3–9: The client establishes a TCP+TLS connection with the endpoint and then makes a standard HTTP request to the web service.
• Step 10: The web service responds to the HTTP request but includes an Alt-Svc header indicating to the client that it can connect using QUIC for HTTP3.
• Steps 11–14: The client initiates a new QUIC connection to the web service and resends the HTTP/3 request. In addition, the client can cache this information based on the max-age (ma) parameter specified in the Alt-Svc header.
• Step 15: The web service responds to the HTTP/3 request.

With HTTPS records, the client becomes aware of the web server’s capabilities and can establish the initial connection with fewer round trips, as illustrated in Figure 2.

Figure 2: HTTP3 connection establishment with HTTPS record.

The request flow can be summarized as:

• Steps 1–4: The client sends a DNS query for the HTTPS record of the endpoint to connect to and receives a DNS response with the alternate endpoint to reach, as well as information on the endpoint’s support for HTTP3. In addition, the client may send additional A or AAAA DNS queries to get the corresponding IPv4 or IPv6 address of the alternate endpoint.
• Steps 5–7: The client establishes a QUIC connection to the endpoint and then makes a standard HTTP/3 request to the web service.
• Step 8: The web service responds to the HTTP/3 request.

Another example of endpoint-specific data that can be sent to the client through DNS is Encrypted Client Hello (ECH). You may be familiar with Encrypted Server Name Identification (ESNI), which is used to improve the privacy of users. ESNI required unique DNS records to advertise the server public TLS key. This key is used by the client to encrypt the Server Name Identification (SNI) field of the ClientHello in transit. In March 2020, ESNI was reworked into a new extension called Encrypted Client Hello (ECH). ECH supports the encryption of the entire ClientHello rather than just the SNI value within it. The ECH handshake process for major web browsers relies on HTTPS resource records to provide the servers public key for encrypting the client hello to the server.

TLSA record

Domain Name System Security Extensions (DNSSEC) is becoming a common configuration for domains. DNSSEC helps validate the answer that recursive resolvers receive from authoritative DNS servers, to ensure that the answer wasn’t manipulated in transit. Establishing a secure connection to the server through TLS requires separate validation of the certificate name and public key. The DNSSEC and TLS validation processes are separate, and each needs to work together to provide a trusted DNS response and a validated TLS certificate issued by a trusted authority.

DNS-based Authentication of Named Entities (DANE) is a protocol designed to leverage DNSSEC infrastructure to bind public key data to DNS names. Because the binding occurs inside the DNSSEC infrastructure, it limits the scope of TLS assertions by a domain to the DNS hierarchy. DNSSEC, DANE, and TLS work together to create a trusted path from the DNS server, an expected public key for a server, and the server to prove its identity by providing the expected key that is validated by a certificate authority (CA). A key component of the DANE protocol is a new DNS resource record type called the TLSA record.

TLSA records allow administrators to specify a public key fingerprint of the TLS certificate in DNS. This enables a TLS client to verify using DNS that the certificate presented by a server is expected from the DNS owner’s perspective. If they don’t match, it could indicate a compromise or configuration error for the service.

When you add a TLSA record to your hosted zone, the record name must include the port and protocol, while the record value is composed of four fields separated by spaces, as shown below:

_port._protocol.domain-name TTL IN TLSA [certificate-usage-field] [selector-field] [matching-type-field] [certificate-data]

For more details on the different values for each field, you can have a look at the Route 53 Developer Guide. The following DNS record shows an example of what a TLSA record for a mail server looks like:

_25._tcp.mail.example.com 300 IN TLSA 3 1 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971

This TLSA record matches a SHA-256 hash of the public key information in the certificate presented by the server.

A major use case for DANE and TLSA is SMTP over TLS. SMTP over TLS generally is opportunistic and isn’t a requirement. It can be configured to fail through to unencrypted protocols, making it vulnerable to downgrade attacks because the client cannot determine what the server supports before it attempts to connect to the server. The presence of a TLSA record and associated DANE policy allows for secure mail transfer that is resistant to downgrade attacks. It provides the SMTP client a way to validate that the public key fingerprint for the server matches the expected value returned by the TLSA record.

Figure 3 shows an exchange between two mail servers when one client (alice@example.com) sends an email to another client (bob@example.org).

Figure 3: SMTP without DANE/TLSA validation.

At a high level, the entire exchange between both mail servers can be summarized as:

• Steps 1–4: The sending mail server performs a mail exchanger (MX) lookup to identify the main server for the domain of the recipient. This may be followed by a A or AAAA lookup to identify the corresponding IPv4 or IPv6 address.
• Steps 5–7: The sending mail server establishes a TCP connection with the receiving mail server and attempts to initiate an SMTP connection.
• Steps 8–9: The receiving mail server responds and indicates that it supports the STARTTLS capability.
• Steps 9–13: The sending mail server responds to the receiving mail server, indicating that it is ready to start a TLS session, after which both endpoints then establish a TLS connection. This TLS connection is only established if both parties successfully communicate that they support and would like to use TLS. If the TLS connection cannot be established, the sending mail server can still attempt to send the email unencrypted.
• Step 14: If the TLS connection was successfully established, the email is sent over this encrypted connection.

Figure 4 illustrates a high-level exchange between both mail servers when using DANE with TLSA:

Figure 4: SMTP Handshake with DANE/TLSA validation.

Now with TLSA validation, the entire exchange between both mail servers can be summarized as:

• Steps 1–4: The sending mail server does an MX lookup to identify the main server for the domain of the recipient, as well as a TLSA lookup to identify the fingerprint of the receiving mail server. This may be followed by a A or AAAA lookup to identify the corresponding IPv4 or IPv6 address.
• Steps 5–6: If a TLSA record is obtained for the receiving mail server and the chain of trust is validated through DNSSEC, then the sending mail server will only attempt to send the email over an encrypted connection.
• Steps 7–9: The sending mail server establishes a TCP connection with the receiving mail server and then sends a ClientHello to initiate a TLS connection with the receiving mail server.
• Step 10: The receiving mail server responds with a Server Hello, and other parameters required for the TLS handshake, one of which is its certificate.
• Steps 11–13: The sending mail server validates the certificate presented by the receiving mail server against the fingerprint received from the TLSA record. If validation is successful, the sending mail server proceeds to complete the TLS handshake and then initiate the SMTP handshake over this encrypted connection. If validation is not successful, the connection is torn down, and the email is not sent.
• Step 14: Once the SMTP connection is established over the TLS connection, the email is sent over the encrypted connection.

SSHFP record

SSH relies on mutual key authentication by the client and server. Clients need to trust the server key fingerprint to verify the server key is what they expect. Managing this at scale can be challenging, and allowing users to trust a fingerprint manually is error-prone and increases the risk of human error.

Figure 5: SSH connection fingerprint validation.

SSHFP DNS records allow DNS servers to answer an SSH client request for SSH fingerprints with a DNSSEC-signed set of records that contain the SSH fingerprints. The SSH client then validates the fingerprint a server presents with those provided by the DNS server. This combination of DNSSEC chain of trust to validate the authenticity of an SSHFP record and subsequent verification of SSH fingerprints help mitigate man-in-the-middle attacks and improve the overall security of a system.

When you add an SSHFP record to your hosted zone, the record name must be the domain name of the entity to be connected to, while the record value is composed of three fields separated by spaces, as shown below:
fully-qualified-domain-name TTL IN SSHFP [key-algorithm] [hash-type] [fingerprint]
For more details on the different values for each field, check out the Route 53 Developer Guide for this.

The fingerprint needs to be generated on the server to be connected to. Here, we show an example using the ssh-keygen command to generate that fingerprint, but there are other utilities that can be used to generate the fingerprint, which can then be added to a DNSSEC-signed hosted zone:

$ ssh-keygen -r test-srvr01.example.com
test-srvr01.example.com IN SSHFP 1 1 f38c20526d7d3f5bea3f4ff45f0e7b516f9d7c86
test-srvr01.example.com IN SSHFP 1 2 e40f64e936ffec2d23c04bbe0d847dcb76a6b3e7ed6d7c2e9bee9881bcacf6ce
test-srvr01.example.com IN SSHFP 3 1 6ef7d74b90f7fcf580d11bf2724ba22f8f38ca1f
test-srvr01.example.com IN SSHFP 3 2 81f482061216fdfa791daa387c533227cb9cf590d0bbc92931281fd6e5048c59
test-srvr01.example.com IN SSHFP 4 1 6b3f7e580c687592d2c5cc98dc8f28f08e1fd48d
test-srvr01.example.com IN SSHFP 4 2 a8d4603448cd8fa69e45fec581f7652df7f8ee66fc239f8bfa70954747c77f5c

When using SSHFP records to verify SSH fingerprints, the DNS zone must be DNSSEC signed, and the DNSSEC validation must be performed on the client rather than relying on a recursive resolver to carry out the validation. In other words, the client connecting must be able to request DNSSEC validation – that is, set the DO (DNSSEC OK) flag in the DNS query, and the resolver must be able to carry out DNSSEC verification of the SSHFP record.

Conclusion

With the introduction of the new DNS record types, Amazon Route53 now supports four additional record types (SVCB, HTTPS, TLSA, and SSHFP) that provide you with the ability to improve application security and performance. You can get started with creating these new record types in your Route 53 hosted zones using the AWS Management Console, Route 53 API, AWS Command Line Interface (AWS CLI), AWS CloudFormation, and AWS SDKs.

Get started today and let us know your feedback either through your usual AWS Support contacts or the AWS re:Post for Amazon Route 53. You can also visit the Route 53 Developer Guide for more information.

A correction was made on November 7, 2024: An earlier version of this post included an incomplete diagram for the SMTP handshake with DANE/TLSA.

About the authors