Using DNS CAA Records to Restrict Certificate Issuance
A source-grounded guide to CAA issuer lookup, issue and issuewild behavior, deployment errors, and security limits under RFC 8659 and Let's Encrypt operations guidance.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
A DNS Certification Authority Authorization (CAA) record tells public certificate authorities which issuers a domain holder authorizes to issue certificates for a name. A CA checks the applicable CAA data before issuance. CAA is an additional pre-issuance control; it does not replace domain-control validation, certificate validation, or every other protection against mis-issuance.
What CAA controls
RFC 8659 defines CAA as an authorization check performed by a certificate authority before it issues a certificate. When a relevant CAA record set exists, a compliant CA must determine that the request is consistent with the set or that an exception in its certificate policy or practice statement applies. A record can narrow which CA identifiers may issue for a DNS name. It does not remove the CA’s separate domain-control checks, and it does not change how relying software validates a certificate after issuance.
CAA records describe authority at issuance time. Because DNS policy can later change, RFC 8659 says relying parties must not use current CAA data to validate an existing certificate. Keep the CA’s pre-issuance check separate from post-issuance certificate validation.
How a CA finds the relevant record set
For each fully qualified domain name in a certificate request, the CA begins with that name and walks up the DNS name tree until it finds a CAA record set. The first set found is relevant; the search does not continue to combine every ancestor policy. For example, if www.example.com has no CAA record but example.com does, the parent set can apply. A record at a closer child name can provide a more specific policy. RFC 8659’s lookup procedure also follows DNS aliases when obtaining the query result.
A request can contain multiple names, including wildcards, and the CA checks each one. Check the first applicable CAA set for every SAN, delegated subdomain, and alias target. Let’s Encrypt likewise documents nearest-name lookup.
If no relevant set is found, CAA imposes no issuer restriction. A set with only iodef or noncritical properties unknown to the CA also does not restrict issuance. A malformed or unavailable DNS response differs from a valid empty answer.
Understanding issue, issuewild, and flags
The issue property identifies CAs authorized to issue ordinary certificates for the name and, when no issuewild property applies, also controls wildcard issuance. Use issuewild when wildcard permissions should differ. If the relevant set contains at least one issuewild property, the CA ignores issue for a wildcard request and applies the wildcard-specific values. Multiple properties of the same kind are additive: listing more than one issuer can authorize each matching CA, rather than requiring all of them to cooperate.
A CAA record has flags, a tag, and a value. issue names a CA and may include issuer-specific parameters; an empty issuer name requests no issuance. iodef gives a reporting method, not an issuer allow-list. If a CA encounters an unknown property marked critical, RFC 8659 requires it not to issue for that name, so check CA support before setting the flag.
Let’s Encrypt documents CA-specific parameters such as validationmethods and accounturi for restricting validation method or account. These values are issuer-specific; verify support and syntax in the issuing CA’s documentation before using them.
Practitioner perspective: test the DNS path and retain recovery
Before deployment, inspect CAA answers for every exact certificate name, including wildcard names, delegated zones, and aliases. Confirm which ancestor provides the first record set and whether multiple issue values widen the allowed set. Then test the intended issuance and denial cases through the CA’s staging or test process, and record how a policy change can be rolled back if automated renewal starts failing. This validates the actual DNS path and issuer behavior rather than only the record-entry form in a provider dashboard.
Let’s Encrypt’s CAA guide describes common lookup failures such as SERVFAIL, DNSSEC validation problems, authoritative-server outages, and DNS services that reject unknown query types instead of returning the required response. A CAA error does not prove that issuance is authorized: the CA may be unable to determine which policy applies. Check the authoritative DNS service and DNSSEC chain, and involve the DNS provider when the response is malformed or unavailable.
CAA reduces one class of risk but cannot prevent an authorized CA from making a mistake. RFC 8659 recommends DNSSEC validation where possible to help detect suppressed or modified CAA data, while also treating DNSSEC as a separate DNS integrity mechanism. Domain holders should keep their allowed issuer set current and evaluate the authorized CA’s internal issuance controls. CAA should be one documented layer in certificate operations, not a promise that a domain cannot receive an unwanted certificate.