CAA Records and Certificate Authority Authorization

A published list of who may issue for your name

A CAA record names the certificate authorities allowed to issue certificates for your domain. Publish one and every public CA not on the list is obliged to refuse the request, whoever made it and however convincing it looks.

IANA registers the type under value 257 with the meaning certificate authority restriction, and RFC 8659 replaced the original specification in 2019. The record is small: a flags byte, a property tag, and a value. A working configuration can be one line at the apex naming your issuer.

The unusual thing about CAA is where enforcement sits. Nothing you run checks it. The obligation lands on the certificate authority, before issuance, as a condition of being trusted by browsers.

Checking became mandatory in 2017

CAA spent four years as a specification almost nobody honored. That changed with CA/Browser Forum Ballot 187, which made checking a condition of the Baseline Requirements, the rules public CAs follow. The adopted text sets the date plainly: the section is effective as of 8 September 2017.

The requirement is narrower than the summaries suggest. As part of issuance the CA must check for a CAA record for each dNSName in the certificate, following the procedure in the specification, and must process the issue, issuewild and iodef tags. If it issues, it must do so within the record's TTL or eight hours, whichever is greater, so a check cannot be cached and reused indefinitely.

There is a documented exception, and it matters. A CA may treat a lookup failure as permission to issue, provided the failure is outside its own infrastructure, the lookup has been retried at least once, and the zone has no DNSSEC validation chain to the ICANN root. Against mistakes, careless issuance and social engineering, CAA holds. Against an adversary who can interfere with your DNS answers it is weaker, and a signed zone is what closes that gap.

Three tags do the work

The value of a CAA record starts with a property tag that determines what the rest means. Three are in ordinary use.

issue authorizes a CA, identified by the domain name that CA publishes for the purpose. Each issuer gets its own record, so a domain using two providers publishes two. The tag has a second use that is easy to miss: an issue record whose value is a bare semicolon authorizes nobody, which is how a domain that should never hold a certificate says so.

issuewild covers wildcard certificates, and its precedence rule is the one people trip over. With no issuewild record present, the issue records govern wildcard requests too. The moment any issuewild record appears, RFC 8659 requires every issue property to be ignored for wildcard requests, so adding one issuewild record to authorize a single provider removes wildcard authorization from everyone in your issue records.

iodef supplies a mailto, http or https address for reporting requests that violate the policy, and restricts nothing on its own: RFC 8659 is explicit that a record set holding only iodef tags does not restrict issuance. The specification defines the channel but does not oblige a CA to use it. Treat it as a courtesy, and use certificate transparency logs for actual monitoring.

How far up the tree a CA looks

A CA checks more than the exact name on the request. The search climbs the name tree from the requested label upward, stopping at the first CAA record set it finds, up to but not including the root.

Two properties follow, two sides of one rule. An apex record covers every name beneath it that publishes nothing of its own, which is why one line is usually the entire job even for an organization with dozens of subdomains. And a record on a subdomain replaces the apex record for that name rather than adding to it, because the climb stops at the first set found.

The second half is where accidents happen. A team that publishes a narrow record at shop.example.com naming one provider has not tightened the apex policy for that host, it has substituted a different one, and issuers listed only at the apex can no longer obtain a certificate for that name. Publish at a subdomain only with the complete list that should apply there.

The critical flag is narrower than it sounds

The first byte of a CAA record is the flags byte, and one bit is defined: the issuer critical flag, entered as 0 or 128 and shown as the leading number in the record. Almost every published record uses 0.

The flag does not mean the restriction is stricter. It governs what a CA does with a tag it does not recognize: RFC 8659 states that a CA must not issue for a name if the relevant record set contains a critical property for an unknown or unsupported tag. On a plain issue record it changes nothing, because every compliant CA understands issue.

Its real use is specialized and future tags, where marking one critical forces a CA that cannot interpret it to stop rather than continue. On an ordinary issue record the flag achieves nothing and risks blocking issuance you meant to allow, so leave it at 0 unless a tag calls for otherwise.

Publishing one without blocking your own renewals

The work in CAA is the inventory, not the syntax. A list that omits an issuer blocks it completely, and the omission usually surfaces at a renewal months later rather than at publication.

Account for everything that obtains a certificate on your names, including the parties nobody thinks of as certificate providers:

• a CDN or edge platform that issues its own certificate for your hostnames
• a load balancer or cloud service with managed certificates
• a hosting panel that quietly provisions certificates for every new subdomain
• a mail, help desk or e-commerce platform terminating TLS on a name of yours
• a monitoring or preview environment somebody set up on a subdomain years ago

Certificate transparency logs are the practical way to build that list, because they show what has been issued for your names rather than what you remember authorizing. Publish, then confirm the next renewal completes rather than assuming it will.

Two refinements exist once the basics work. RFC 8657 defines an accounturi parameter, which restricts an authorization to one account at that CA, and a validationmethods parameter, which limits the domain control validation methods it may use. Both narrow the grant from any customer of a large CA to your own account. And one warning applies to every zone: a CA that cannot resolve your records may refuse to issue, so unreliable DNS blocks renewals even with no CAA record published.

What CAA cannot do

CAA is checked at issuance and nowhere else, which bounds everything it offers. RFC 8659 states that CAA records describe only current grants of authority to issue, and that because certificates are valid for a period of time, one that does not conform to the records published today may have conformed to those published when it was issued.

So publishing a record does nothing about a certificate that already exists. Browsers never consult CAA, and the specification directs relying parties not to use it in certificate validation. Where an unwanted certificate has been issued, the remedy is revocation and a conversation with the CA that issued it, not a DNS change.

The specification is equally frank about the rest. CAA does not prevent mis-issuance by a CA your records do authorize, so keep the list short. Suppression or insertion of records by an attacker able to interfere with DNS could let an unauthorized CA issue, which is the exposure the DNSSEC condition describes from the other direction.

Set against that, the cost is one DNS record and an afternoon of inventory, with nothing to install and nothing to renew. It removes an entire class of issuance by authorities you have no relationship with. The benefit is narrow, the price is close to nothing, and it stays a strange trade for so many domains to decline.