13 of 13 shown
The first field of a TLSA record.
| Value | Acronym | Description | References |
|---|---|---|---|
0Note | PKIX-TA | PKIX-TA (0) is the TLSA certificate usage “CA constraint”. | RFC 6698 |
1 | PKIX-EE | PKIX-EE (1) is the TLSA certificate usage “Service certificate constraint”. | RFC 6698 |
2Note | DANE-TA | DANE-TA (2) is the TLSA certificate usage “Trust anchor assertion”. | RFC 6698 |
3Note | DANE-EE | DANE-EE (3) is the TLSA certificate usage “Domain-issued certificate”. | RFC 6698 |
255 | PrivCert | PrivCert (255) is the TLSA certificate usage “Reserved for Private Use”. | RFC 6698 |
| Range | Status | Description |
|---|---|---|
| 4–254 | unassigned | Unassigned |
Source: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), retrieved 2026-10-20. Data license: CC0-1.0. TLSA Certificate Usages
PKIX-TA (0) requires a chain to a public CA and that the CA match the TLSA record; RFC 7672 advises against it for SMTP.
Usages 0 and 1 add a DNS constraint on top of ordinary Web PKI validation. For SMTP between mail servers, RFC 7672 §3.1.3 says TLSA records SHOULD NOT use them: an attacker who can forge DNS can replace them anyway, and mail servers share no common list of trusted CAs.
DANE-TA (2) pins a trust anchor — usually the issuing CA — in DNS.
With usage 2 the server's chain must lead to the certificate or key in the TLSA record, which need not be a public CA. RFC 7672 §3.1.2 requires the server to send the trust anchor in its chain when the record matches a key rather than a full certificate.
DANE-EE (3) pins the server's own certificate or key in DNS; names and expiry in the certificate are not checked.
With usage 3 the TLSA record alone binds the key to the name: RFC 7672 §3.1.1 says the server is authenticated even if no name in the certificate matches and that the certificate's expiry date MUST be ignored. The common record '3 1 1' (DANE-EE, SPKI, SHA-256) survives certificate renewals as long as the key stays the same.
The second field of a TLSA record.
| Value | Acronym | Description | References |
|---|---|---|---|
0 | Cert | Cert (0) is the TLSA selector “Full certificate”. | RFC 6698 |
1 | SPKI | SPKI (1) is the TLSA selector “SubjectPublicKeyInfo”. | RFC 6698 |
2 | C509 | C509 (2) is the TLSA selector “C509Certificate”. | RFC-ietf-cose-cbor-encoded-cert-21 |
255 | PrivSel | PrivSel (255) is the TLSA selector “Reserved for Private Use”. | RFC 6698 |
| Range | Status | Description |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Source: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), retrieved 2026-10-20. Data license: CC0-1.0. TLSA Selectors
The third field of a TLSA record.
| Value | Acronym | Description | References |
|---|---|---|---|
0 | Full | Full (0) is the TLSA matching type “No hash used”. | RFC 6698 |
1 | SHA2-256 | SHA2-256 (1) is the TLSA matching type “256 bit hash by SHA2”. | RFC 6234 |
2 | SHA2-512 | SHA2-512 (2) is the TLSA matching type “512 bit hash by SHA2”. | RFC 6234 |
255 | PrivMatch | PrivMatch (255) is the TLSA matching type “Reserved for Private Use”. | RFC 6698 |
| Range | Status | Description |
|---|---|---|
| 3–254 | unassigned | Unassigned |
Source: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), retrieved 2026-10-20. Data license: CC0-1.0. TLSA Matching Types