CAA Records Restrict Certificate Authority Issuance

A public certificate authority can issue a certificate only after satisfying its validation and policy requirements. DNS Certification Authority Authorization adds another control: the domain holder can publish a CAA resource record set that states which issuers are authorized for a name.

CAA is an issuance constraint, not a replacement for domain-control validation. An authorized CA still has to perform the validation required by its certificate policy. Conversely, successful domain validation does not permit a compliant CA to disregard an applicable CAA restriction.

The relevant RRset can come from a parent name

RFC 8659 defines a search for the relevant CAA RRset. For a requested FQDN, processing starts at that name and can climb toward the DNS root until a CAA RRset is found. The search stops at the first applicable RRset rather than combining policy from every ancestor.

That behavior permits a registered domain to set a broad policy while a more specific name publishes its own CAA policy. A child RRset is therefore not an additive refinement of the parent’s records; once it is the relevant RRset, its contents govern that lookup.

CAA processing also accounts for DNS aliases. A CNAME encountered during the lookup changes where CAA processing continues, so certificate automation needs to consider alias targets rather than inspecting only the visible application hostname.

issue authorizes ordinary issuance

The issue property identifies an issuer that may issue certificates for the name covered by the relevant RRset. A basic record has this shape:

example.org.  CAA 0 issue "ca.example"

Multiple issue properties are additive. If the relevant RRset contains several authorized issuers, a CA can proceed when one applicable property authorizes it, subject to the rest of its issuance requirements.

An empty issuer value can be used to deny authorization through that property. This is materially different from publishing no CAA RRset: absence of a restrictive CAA policy does not itself select a particular CA.

issuewild has separate wildcard semantics

Wildcard certificate requests have an additional policy path. The issuewild property uses the same general value syntax as issue, but applies only to wildcard domain names.

example.org.  CAA 0 issue     "ca-a.example"
example.org.  CAA 0 issuewild "ca-b.example"

When at least one issuewild property is present in the relevant RRset for a wildcard request, the issue properties are ignored for that wildcard authorization decision. In this example, the wildcard policy is not an extra permission layered on top of issue; it is the applicable issuer set for wildcard issuance.

For a non-wildcard FQDN, issuewild does not participate in the authorization decision.

The critical flag changes handling of unknown properties

A CAA record contains flags, a property tag, and a property value. Bit 7 of the flags field is the issuer-critical flag. Its common numeric representation is 128.

If a CA encounters an unknown property with that flag set, it cannot safely treat the property as irrelevant and continue issuance. The critical marker signals that correct processing of the property matters to the domain holder’s policy.

Known properties do not become stronger merely because the bit is set. The flag primarily governs behavior when the issuer does not recognize the property tag.

CAA constrains issuers, not certificate use

CAA is evaluated by certificate issuers before issuance. Browsers do not consult CAA records when deciding whether to accept a certificate during an ordinary TLS connection, and changing a CAA RRset does not revoke certificates that were already issued.

That boundary matters during incident response. Tightening CAA can constrain later issuance, but an existing unwanted certificate requires the revocation and replacement procedures applicable to that certificate and CA ecosystem.

CAA also does not authenticate DNS data to relying-party browsers. DNSSEC and CAA address different protocol properties. CAA defines an issuance authorization signal in DNS; DNSSEC can provide origin authentication and integrity for signed DNS data where it is deployed and validated.

DNS availability is part of issuance reliability

A CA must be able to determine the applicable CAA state before it can rely on the result. DNS failures can therefore block issuance even when the domain holder did not intend to restrict a CA. Treating lookup failure as equivalent to an unrestricted answer would erase the control whenever DNS resolution became unreliable.

Operationally, CAA belongs in the same change discipline as other certificate automation inputs. DNS migrations, CNAME changes, delegated subdomains, and issuer changes can alter the effective policy seen during issuance.

The useful security property is narrow and concrete: CAA lets a domain holder reduce the set of certificate authorities permitted to issue for a name. It does not certify that an authorized issuance is correct, revoke existing certificates, or replace validation. Its value comes from placing an independently managed authorization boundary in the certificate issuance path.