DNS CAA record

What it means

A DNS CAA (Certification Authority Authorization) RRset expresses which certificate authorities may issue specified certificates for a domain. A CA examines the relevant CAA policy along the applicable lookup path before issuance. issue addresses ordinary issuance, and issuewild provides a policy for wildcard requests where present. CAA is an issuance restriction, not a browser trust chain, proof of ownership, or a way to revoke an already-issued certificate.

Try it

Simulation — choose a certificate request. Select ordinary or wildcard, issuer A or B, and a synthetic policy at the requested name, an ancestor or a closer override. Switch the authorized issuer and see which one passes the policy gate. Select an unknown critical flag or a retrieval error to stop rather than pretending no restriction exists. Reset restores the request and decision.

How the mechanism works

CAA records are looked up at a relevant name and, subject to CNAME and tree-walk rules, may involve ancestors. A closer applicable RRset is used instead of merging all ancestor restrictions. For wildcard issuance, an applicable issuewild tag takes precedence over issue; otherwise the issue rule can apply. Tag and flag handling matters: unknown critical tags are not a reason to silently authorize issuance. Real CA implementations must also perform the other verification procedures governing certificate issuance.

A domain can carry a restriction permitting one CA but not another without changing which certificate clients already trust. The model's invented issuer labels avoid suggesting that either provider has been endorsed. If DNS policy lookup fails, an issuer cannot equate unavailable evidence with confirmed absence of policy.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

Before editing CAA in production, obtain an inventory of the certificates and issuers in active use, including renewal and wildcard needs. Read existing records and provider-specific validation policies; make a narrowly reviewed change only through authorized zone management. Keep a copy of the original RRset and identify the responsible renewal system. Stop if you cannot account for required issuers, the effective ancestor policy or an unrecognized critical tag. Verify issued-certificate workflows separately; restore the reviewed record if a change disrupts permitted renewals.

Limits and common mistakes

This is an educational lookup with only two synthetic issuers and a simplified tree, not a complete CAA parser or real-time CA issuance authorization. Issuer-specific extensions, validation methods, CNAME processing and errata can affect operational behavior. A permitted model result is not a promise of issuance.

Key takeaways

CAA constrains which CA may issue under the relevant RRset; it does not revoke an existing certificate or replace certificate validation. A closer CAA RRset changes which policy is consulted; wildcard issuance can be governed by issuewild. Treat a failed lookup or unknown critical property as a stop condition for the modeled issuance check.