3.1.5.12. TLSA

Important points:

  • Before adding a record, DNSSEC must be enabled.
  • Whenever you change servers or certificates, you must immediately update the TLSA record; otherwise, clients may detect a mismatch and reject the connection. Before performing such actions, first add a new TLSA record without deleting the old one, wait for the DNS cache to update, make the necessary changes on the server, verify that the new record is working, and only then delete the old one.

General information

TLSA record (Transport Layer Security Authentication) — a special DNS record that associates a server’s TLS/SSL certificate or public key with the domain where the record is located. It is part of the DANE (DNS-based Authentication of Named Entities) security protocol, which allows domain owners to specify which certificates should be trusted during TLS connections to servers serving those domains. For more information, see RFC 6698.

When a client connects to the server via a secure TLS connection, the server provides the client with a certificate chain. To verify their authenticity, the client compares the received certificate chain with the data from the TLSA record in accordance with the rules specified in the record. If the data matches, the connection proceeds; if the certificate does not match the TLSA record, the connection is rejected. If a TLSA record is published but DNSSEC is not functioning or the record is unavailable, the client may not trust the connection. Thus, TLSA helps prevent "man-in-the-middle" attacks and certificate spoofing, and for SMTP, it helps prevent unencrypted delivery when a server attempts to switch to an unsecured connection.

TLSA can be used for HTTPS, SMTP, XMPP, LDAP, SIP, and other services that use TLS. Browsers typically do not verify TLSA for HTTPS, so in practice, TLSA is most commonly used to secure mail servers and mail transfer via SMTP.

Requirements

Requirements for working at TLSA:

  • DNSSEC is enabled.
  • The host, port, and protocol are specified correctly in the record name.
  • The data of the valid certificate or key is specified in the record data.
  • TLS is used for the connection.
  • The client supports DANE technology.

Record format

Each TLSA record consists of a subdomain and data.

Subdomain

Subdomain name format: 

_<port>._<protocol>.<host>

The subdomain name contains information about where and how the client connects:

  • Port number (for example, 25).
  • Protocol name (for example, _tcp).
  • A hostname without a top-level domain (for example, mail or www).

For SMTP, port 25 is typically used, and a TLSA record is added for the host specified in the domain's MX record.

Examples: 

_25._tcp.mail.example.com
_443._tcp.www.example.com

Data

Data format: 

<Usage> <Selector> <Matching type> <Certificate association data>

First number (Usage) — how to verify a certificate:

  • 0 — the certificate must be issued by a trusted public certificate authority.
  • 1 — the certificate for the service itself is verified, but a standard verification through a CA is also required.
  • 2 — the trusted certification authority or root certificate is specified.
  • 3 — the server certificate or its public key is verified directly.

Second number (Selector) — what to use for validation:

  • 0 — full certificate.
  • 1 — public key only.

Third number (Matching type) — how data is stored:

  • 0 — a full certificate or a key without hashing.
  • 1 — SHA-256 hash.
  • 2 — SHA-512 hash.

The last field (Certificate association data) — a fingerprint or certificate that must be matched against the one provided by the server. This is usually a long string of letters and numbers.

The most common form of record looks like this: 

3 1 1 <SHA-256 hash of public key>

Examples: 

3 1 1 1306c288896771534a5b60744a535e1025f79b0b64e1bbc89278ba4d413cb9f1
Content