Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
Extracted elements (21)
Application developers may perform address queries and TLSA queries in parallel to reduce connection latency. Because a TLSA record can be ignored if its corresponding address record is not 'secure', this parallelism is safe from a security perspective.
The long-term goal is TLS certificates that verify the target server hostname rather than the service domain name, as this scales better for multi-tenanted environments and simplifies server certificate management. The disadvantage is that non-DANE clients must use RFC 6125 name checks against the service domain name, requiring SNI support for backward compatibility.
TLSA records are placed under the target server hostname (not the service domain name) because the certificate is part of server configuration, certificate replacement requires updating only one DNS location, and some protocols (e.g., SMTP) allow transactions with multiple service domains per connection making service-domain TLSA records infeasible.
Servers using only DANE-EE TLSA records may prevent clients that do not support this specification from successfully connecting with TLS, since those clients will check the certificate against the service domain name per RFC 6125. SNI support or its functional equivalent is therefore necessary for backward compatibility in multi-tenanted environments.
When SRV is secure and no usable TLSA records exist, the client accepts either the service domain name or the target server hostname as a valid identity, ensuring compatibility with servers that support this specification as well as those that do not.
For TLSA records with certificate usage types other than DANE-EE, the certificate MUST contain an identifier matching either the service domain name (SRV query domain) or the target server hostname (SRV target hostname), or both.
If an address (A or AAAA) RRset for an SRV target is 'secure', the client MUST perform a TLSA query for that connection endpoint. If no address RRsets are 'secure', the client MUST NOT perform a TLSA query for that endpoint.
If any DNS queries are for internationalized domain names, the A-label form (RFC 5890) MUST be used.
If the address record lookup for an SRV target fails with a 'bogus' or 'indeterminate' validation status, the client MUST NOT connect to that connection endpoint and MUST use the next most appropriate SRV target, helping prevent downgrade attacks.
If the SRV lookup returns a 'bogus' RRset or fails for reasons other than no records, the client MUST abort its attempt to connect to the desired service. If the result is 'insecure' or no SRV records exist, the client SHOULD fall back to non-DNSSEC, non-DANE behavior.
If the TLS server certificate or its public key matches a usable TLSA record with certificate usage DANE-EE, the client MUST ignore PKIX validation checks (RFC 5280) and reference identifier checks (RFC 6125), since the DANE-EE record supersedes non-key information in the certificate.
If the TLSA response is 'insecure' or no TLSA records exist, the client SHALL proceed as if the target has no TLSA records and MAY connect with or without TLS, subject to application protocol or client policy.
If the TLSA response is 'secure' and usable, the client MUST use TLS when connecting to the target server. If the TLSA response is 'bogus' or 'indeterminate', the client MUST NOT connect to that target server.
If there are zero usable TLSA records, the client SHALL validate the server certificate using PKIX or protocol-specific rules. It SHOULD use TLS SNI (RFC 6066) or its protocol equivalent, with the service domain name as the preferred name.
Reference identifier construction when no TLSA records are usable depends on SRV security: if SRV is insecure, identifiers SHALL include the service domain name and MUST NOT include the SRV target server hostname; if SRV is secure, identifiers SHALL include both the service domain name and the SRV target server hostname.
Server operators MUST secure published SRV records and subsequent A/AAAA records with DNSSEC. There SHOULD also be at least one TLSA record published that authenticates the server's certificate.
The entire chain of DNS RRsets returned in response to an SRV query MUST be 'secure' according to DNSSEC validation (RFC 4033/4035), including any CNAME/DNAME aliases in the chain, for this specification to apply.
When connecting, the client MUST use TLS if both the SRV and TLSA query responses were 'secure'. TLS certificate validation then follows either Section 4.1 (no usable TLSA records) or Section 4.2 (at least one usable TLSA record).
The client SHALL construct the TLSA query name per RFC 6698 Section 3, using the port number from the SRV RDATA, the transport protocol from the SRV query name, and the TLSA base domain from the SRV target server hostname (not the service domain name). For example, SRV target imap.example.net on port 9143/tcp yields query _9143._tcp.imap.example.net TLSA.
Mixed security status among SRV target endpoints is permitted to allow partial or incremental deployment. However, SRV sorting rules are unchanged and do not prioritize secure over insecure endpoints; a partial deployment is not considered secure and no special accommodation is made for it.
Name checks are unnecessary when the matching TLSA record is certificate usage DANE-EE, as that record already identifies the specific certificate or public key. For other usage types, clients must check reference identifiers because DNSSEC+TLSA only binds to a CA, and third parties can obtain certificates from the same CA.