DNS Certification Authority Authorization (CAA) Resource Record
obsoletes
- rfc-6844 — DNS Certification Authority Authorization (CAA) Resource Record
Extracted elements (25)
CAA authorizations are additive: specifying both an empty issuer-domain-name and a non-empty issuer-domain-name is equivalent to specifying only the non-empty name. This simplifies multi-CA scenarios and avoids implicit denials from partial record sets. Issuers MAY also accept parameters (e.g., account numbers) in the issue value, whose semantics are determined solely by the Issuer.
CAA records are a pre-issuance authorization control performed by the CA, whereas TLSA (DANE) records are a post-issuance verification control performed by Relying Parties. Conformance with CAA is necessary but not sufficient for certificate issuance.
RFC 6844's tree-climbing algorithm also climbed CNAMEs and DNAMEs, making processing inefficient for FQDNs with many aliases and making it difficult for hosting providers to set CAA policies without imposing unwanted policies on customers. RFC 8659 simplifies the algorithm to climb only the FQDN being processed, delegating CNAME/DNAME resolution to the CA's recursive resolver.
A signed empty CAA response is meaningfully different from a bogus response: it proves no CAA policy exists at that label. Known bugs in at least two authoritative resolvers (including PowerDNS prior to 4.0.4) caused incorrect signing of empty RRsets when combined with mixed-case (DNS 0x20) queries, producing bogus DNSSEC responses for CAA lookups.
FQDN administrators who delegate a subdomain to a private nameserver will cause CAs to receive SERVFAIL when looking up CAA records. Administrators wishing to issue certificates for such FQDNs SHOULD use split-horizon DNS with a publicly available nameserver that returns a valid, empty CAA response.
Some middleboxes drop DNS packets of unknown types, manifesting as timeouts or SERVFAIL. Some authoritative nameservers return REJECTED or NOTIMP for unrecognized RR types, and at least one produces a malformed response with the QR bit set to 0; the correct RCODE per RFC 1034 is 0 (No error condition).
Before issuing a certificate, a compliant CA MUST check for publication of a Relevant RRset. If such an RRset exists, the CA MUST NOT issue a certificate unless the request is consistent with the applicable CAA RRset or an exception in the relevant CP or CPS applies.
DNS records compliant with this CAA specification MUST clear (set to 0) all reserved flag bits (bits 1–7). Applications that interpret CAA records MUST ignore the value of all reserved flag bits.
Issuers MUST verify authorization for all FQDNs and Wildcard Domain Names specified in a certificate request, since a request MAY specify more than one FQDN or Wildcard Domain Name.
Relying Parties MUST NOT use CAA records as part of certificate validation. CAA records describe only current grants of authority; a previously issued certificate may have been conformant with CAA records at the time of issuance.
The Tag Length field MUST be at least 1. Tags MUST NOT contain any characters other than ASCII letters (a–z, A–Z) and digits (0–9); matching of tags is case insensitive. Tags submitted for IANA registration MUST use only lowercase ASCII letters and digits.
When processing a wildcard certificate request, if at least one issuewild Property is specified in the Relevant RRset, each issue Property MUST be ignored. Issuewild takes precedence over issue specifically and exclusively for wildcard domain name requests.
A CAA RR contains a single Property (tag-value pair). An FQDN MAY have multiple CAA RRs, and a given Property Tag MAY appear more than once. The canonical presentation format is: CAA <flags> <tag> <value>, where flags is 0–255, tag is lowercase ASCII alphanumeric, and value is a contiguous string or quoted string with no 255-character limit.
The CAA 'iodef' Property specifies a URL for reporting certificate mis-issuance. Supported URL schemes are 'mailto:' (IODEF report as MIME email attachment), 'http:', and 'https:' (submitted as a web service request per RFC 6546). The iodef Property does not restrict certificate issuance.
The CAA 'issue' Property Tag requests that Issuers perform CAA issue restriction processing for the FQDN and grants authorization to issue certificates to the named issuer-domain-name. An empty issuer-domain-name (e.g., 'issue ";"') requests that no certificates be issued by any Issuer. Malformed issue-values that do not match the ABNF MUST be treated as specifying an empty issuer-domain-name.
The CAA 'issuewild' Property Tag has the same syntax and semantics as 'issue' but applies only to Wildcard Domain Names. When at least one issuewild Property is present in the Relevant RRset for a Wildcard Domain Name, each issue Property MUST be ignored for that wildcard request. Each issuewild Property MUST be ignored when processing a request for a non-wildcard FQDN.
The Issuer Critical Flag (bit 0 of the Flags octet, value 128) signals that a Property is critical. A CA MUST NOT issue certificates for any FQDN if the Relevant RRset contains a CAA critical Property for an unknown or unsupported Property Tag. This mechanism allows future CAA versions to introduce mandatory semantics.
IANA maintains the 'Certification Authority Restriction Flags' and 'Certification Authority Restriction Properties' registries. This document (RFC 8659) replaces RFC 6844 as the reference for both registries and updates the CAA TYPE entry in the 'Resource Record (RR) TYPEs' subregistry of the 'Domain Name System (DNS) Parameters' registry.
A CA could abuse the critical flag to trick customers into publishing records that prevent competing CAs from issuing certificates. In practice this attack is of minimal effect, since a blocked competitor would investigate and report the situation to the customer.
A malformed or malicious CAA RR could enable a DoS attack via modification of authoritative DNS records or spoofing of inflight DNS responses. This is not considered to add significantly to the existing risk of running an insecure DNS service; the DNS protocol's maximum name length also bounds the attack surface.
CAA records do not prevent mis-issuance by an authorized CA. FQDN holders SHOULD verify that authorized CAs employ appropriate controls to ensure certificates are issued only to authorized parties within their organization.
Suppression or spoofing of a CAA record could enable an attacker to obtain a certificate from an unauthorized Issuer. Issuers SHOULD perform DNSSEC validation to detect missing or modified CAA RRsets. When DNSSEC is unavailable, DNS lookups SHOULD be performed against authoritative nameservers; third-party cached data MUST NOT be the sole source of CAA information.
The use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED. An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRset, irrespective of whether the corresponding DNS records are signed. DNSSEC provides proof of non-existence, enabling distinction between an empty RRset and a suppressed response.
The Relevant RRset for a domain X is determined by climbing the DNS name tree: starting at X, if CAA(X) is non-empty return it; otherwise move to Parent(X) and repeat until the DNS root is reached, returning Empty if no CAA RRset is found. CNAME/DNAME processing is left to the recursive resolver.
The CAA RDATA section contains one Property consisting of: a 1-octet Flags field (bit 0 is the Issuer Critical Flag), a 1-octet Tag Length field, a variable-length Tag (ASCII alphanumeric), and a variable-length Value field occupying the remaining octets (m = d - n - 2).