DNS Certification Authority Authorization (CAA) Resource Record
obsoleted by
- rfc-8659 — DNS Certification Authority Authorization (CAA) Resource Record
Extracted elements (29)
CAA authorizations are additive: specifying both an empty issuer (";") and a named issuer is equivalent to specifying only the named issuer. This simplifies policy composition and avoids subtle interactions when multiple CAA RRs are present.
CAA records are an issuance-time authorization control checked by the CA before issuance, whereas DANE TLSA records are a post-issuance verification control checked by relying parties. The two mechanisms are complementary and address different points in the certificate lifecycle.
The critical flag is designed to allow future CAA versions to introduce new semantics that MUST be understood for correct processing, preventing conforming CAs that do not recognize the new semantics from issuing certificates. This provides forward-compatible extensibility without backward-compatibility breaks.
Relying Applications MUST NOT use CAA records as part of certificate validation because a certificate that is not conformant with currently published CAA records may have been conformant when issued. CAA records MAY be used by Certificate Evaluators only as a possible indicator of a policy violation.
The property tags auth, path, and policy are reserved in the CAA Restriction Properties registry because deployed clients already implement them from an expired draft (HB2011). Reuse of these tags for a different purpose could cause unexpected behavior in existing implementations.
When resolving CAA records, CNAME and DNAME aliases at the queried label are followed before climbing to the parent domain. This alias-following step occurs at each level of the hierarchy before the parent lookup, ensuring aliases are consistently honored.
Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the request is consistent with the applicable CAA RRset or an exception in the relevant CP/CPS applies.
Data cached by third parties MUST NOT be relied on for CAA record lookups but MAY be used to support additional anti-spoofing or anti-suppression controls. Where DNSSEC is not deployed, all portions of the DNS lookup SHOULD be performed against the authoritative name server.
DNS records compliant with this version of the CAA specification MUST clear (set to '0') all reserved flags bits. Applications that interpret CAA records MUST ignore the value of all reserved flag bits.
Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.
Issuers MUST verify authorization for all the domains and wildcard domains specified in a certificate request. The search for a CAA record climbs the DNS name tree from the specified label up to but not including the DNS root '.'.
issuewild properties MUST be ignored when processing a request for a non-wildcard domain. If at least one issuewild property is specified in the relevant CAA RRset, all issue properties MUST be ignored when processing a request for a wildcard domain.
Relying Applications MUST NOT use CAA records as part of certificate validation. CAA records describe only current grants of authority to issue certificates and a previously issued certificate may have been conformant at time of issuance.
Use of DNSSEC to authenticate CAA RRs is strongly RECOMMENDED but not required. An issuer MUST NOT issue certificates if doing so would conflict with the relevant CAA RRset, irrespective of whether the DNS records are signed.
A CAA RR consists of a one-octet Flags field and a tag-value pair (property). Multiple CAA RRs MAY be published at a domain name. The Issuer Critical flag (bit 0, MSB) signals that the property tag MUST be understood for correct processing.
The 'iodef' property tag specifies a URL (mailto:, http:, or https:) to which an issuer MAY report certificate issue requests inconsistent with the issuer's CP/CPS. Reports use the IODEF format (RFC 5070).
The 'issue' property tag authorizes the holder of the specified issuer domain name to issue certificates for the domain in which the property is published. An issue value with no domain name (e.g., ";") requests that no certificates be issued by any CA.
The 'issuewild' property tag has the same syntax and semantics as 'issue' but applies exclusively to wildcard certificate requests and takes precedence over 'issue' properties when both are present for a wildcard domain.
IANA assigned DNS Resource Record Type 257 to the CAA record in the 'Resource Record (RR) TYPEs' registry, with meaning 'Certification Authority Restriction'.
IANA created the 'Certification Authority Restriction Flags' registry. Flag 0 is the Issuer Critical Flag; flags 1–7 are reserved. Assignment of new flags follows the RFC Required policy (RFC 5226 Section 4.1).
IANA created the 'Certification Authority Restriction Properties' registry. Initial tags: issue (Authorization Entry by Domain), issuewild (Authorization Entry by Wildcard Domain), iodef (Report incident by IODEF report), and auth/path/policy (reserved). New tags require public specification and Expert Review.
A CA could abuse the critical flag to trick customers into publishing CAA records that block competing CAs, even though the customer intends to authorize multiple providers. In practice this attack has minimal effect as a blocked competitor would investigate and notify the customer.
CAA records do not prevent mis-issue by an authorized CA. Domain name holders SHOULD verify that authorized CAs employ appropriate controls to ensure certificates are issued only to authorized parties within the holder's organization.
Introduction of a malformed or malicious CAA RR could theoretically enable a DoS attack against an issuer, but the DNS protocol's maximum name length limits the exposure and CAA processing does not meaningfully exacerbate existing DNS DoS risks.
Suppression or spoofing of CAA records could enable an attacker to obtain a certificate from an unauthorized issuer. Issuers SHOULD perform DNSSEC validation to detect missing or modified CAA RRsets; where DNSSEC is unavailable, lookups SHOULD go directly to the authoritative name server.
CAA lookup algorithm for domain X: (1) If CAA(X) is non-empty, R(X) = CAA(X); else (2) if A(X) (CNAME/DNAME alias) is non-null and R(A(X)) is non-empty, R(X) = R(A(X)); else (3) if X is not a TLD, R(X) = R(P(X)) where P(X) is the parent label; else (4) R(X) is empty.
The CAA RDATA consists of: Flags (1 octet), Tag Length (1 octet, value MUST be ≥1 and SHOULD be ≤15), Tag (Tag Length octets of US-ASCII alphanumerics, case-insensitive), and Value (remaining octets; length m = d - n - 2 where d is RDATA length and n is tag length).
The canonical presentation format is: CAA <flags> <tag> <value>, where flags is an unsigned integer 0–255, tag is a non-zero lowercase US-ASCII alphanumeric string, and value is the character-string encoding per RFC 1035 Section 5.1.
The 'issue' property value sub-syntax (ABNF): issuevalue = space [domain] space [";" *(space parameter) space], where parameter = tag "=" value. Additional issuer-supplied name-value parameters further constrain issuance policy.