TLSARecordValidator

TLSA (TLS Authentication) record validator

Validates TLSA records according to:

• RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• RFC 7671: The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• RFC 7673: Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records

TLSA allows certificate information to be distributed via DNS to verify TLS server certificates, reducing the need to rely on third-party certificate authorities.

Format:

Example: 3 1 1 a0b9b16969687adf0323d15048fb4fa4c354c4e01594e8956522cfe3566cae74

Usage values (0-3):

• 0 = PKIX-TA (CA constraint) - Certificate must be issued by the listed CA
• 1 = PKIX-EE (Service certificate constraint) - Certificate must match and be valid
• 2 = DANE-TA (Trust anchor assertion) - Certificate must be issued by the listed trust anchor
• 3 = DANE-EE (Domain-issued certificate) - Certificate must match (can be self-signed)

Selector values (0-1):

• 0 = Full certificate - The entire certificate is matched
• 1 = SubjectPublicKeyInfo - Only the public key is matched

Matching type values (0-2):

• 0 = Exact match - Full data is included
• 1 = SHA-256 hash - A SHA-256 hash of the selected data
• 2 = SHA-512 hash - A SHA-512 hash of the selected data

Placement requirements:

• TLSA records should be located at "_port._protocol.hostname"
• Common example: "_443._tcp.www.example.com"

Recommended usage:

• RFC 7671 recommends DANE-EE(3) + SubjectPublicKeyInfo(1) + SHA-256(1) as the most robust configuration (independent of CA validation and certificate expiration)

Security considerations:

• TLSA records REQUIRE DNSSEC for any security benefit
• Without DNSSEC validation, TLSA offers no security advantage
• When CNAME records are used, the entire CNAME chain must be DNSSEC-signed
• When using SRV records, both SRV and TLSA records must be DNSSEC-signed