DNS CAA Narrows Which Certificate Authorities May Issue for a Domain

Publicly trusted TLS certificates are issued by certificate authorities that satisfy browser and operating-system trust requirements. A domain operator normally chooses one CA, but the public trust ecosystem can contain many authorities capable of issuing certificates that clients would accept.

Certification Authority Authorization (CAA) records add a DNS policy at issuance time. A domain can state which CAs are permitted to issue certificates for it. RFC 8659 defines the processing model, including record lookup, property tags, and issuer behavior.

CAA is not a replacement for certificate validation. It constrains issuance before a certificate exists; clients still validate the resulting certificate during TLS.

CAA policy is expressed in DNS

A CAA resource record contains flags, a property tag, and a property value. Two central tags are issue and issuewild.

A simplified zone can contain:

example.com.  CAA 0 issue "ca.example"

The value identifies a CA according to that CA’s documented issuer-domain name. The record indicates that the named issuer is authorized to issue for the domain, subject to the CA’s own validation and policy.

Multiple issue records can authorize multiple CAs:

example.com.  CAA 0 issue "ca-one.example"
example.com.  CAA 0 issue "ca-two.example"

CAA therefore acts as an allowlist, not as a selector that tells a TLS client which certificate it should prefer.

Wildcard issuance can have a separate policy

The issuewild property controls authorization for wildcard certificates. This permits a domain operator to separate ordinary issuance from wildcard issuance.

example.com.  CAA 0 issue "ca-one.example"
example.com.  CAA 0 issuewild "ca-two.example"

In this example, the policy for a non-wildcard certificate and a wildcard certificate can name different issuers.

An issuewild record takes precedence over issue for wildcard authorization under the CAA processing rules. That distinction matters when a deployment intentionally permits a CA for ordinary names but does not want that same authorization to extend automatically to wildcard certificates.

An empty issuer value can deny a class of issuance

CAA also supports an issuer value that does not authorize any CA. A common form is:

example.com.  CAA 0 issue ";"

This expresses that no issuer is authorized through the issue property at that name.

The effect should be evaluated together with the complete CAA record set and the lookup rules. Copying one line into a zone without considering inherited policy, wildcard policy, and the domain’s actual certificate automation can block legitimate issuance.

CAA changes are therefore configuration changes to the certificate lifecycle, not decorative DNS metadata.

Lookup can inherit policy from a parent name

A CA does not simply check one exact DNS owner name and stop. RFC 8659 defines a tree-climbing lookup. If no relevant CAA records are found at a name, processing can continue toward parent labels until a CAA record set is found or the search terminates.

That allows a parent domain to provide policy for descendants that do not publish their own CAA records.

Conceptually:

api.eu.example.com
        |
        | no CAA
        v
   eu.example.com
        |
        | no CAA
        v
     example.com
        |
        +-- CAA policy found

Publishing a CAA record set on a child can establish policy at that point instead of relying on a parent record set. DNS administration therefore needs to account for delegated teams and subdomain ownership rather than assuming one apex policy always governs every name.

CAA constrains CAs, not attackers at the TLS endpoint

CAA is checked as part of certificate issuance. It does not participate in the TLS handshake and is not normally a browser-side authorization check for an already issued certificate.

That boundary is important:

DNS CAA policy
      |
      v
CA issuance decision
      |
      v
certificate
      |
      v
TLS certificate validation

If a valid certificate has already been issued, changing CAA does not revoke it. Revocation, expiration, key rotation, and certificate replacement remain separate lifecycle mechanisms.

Likewise, CAA does not protect a private key stored on a server, enforce application authorization, or prevent a compromised endpoint from using a certificate whose key it already possesses.

DNS integrity affects the value of the control

Because the policy is published in DNS, the integrity and availability of the relevant DNS path matter. CAs are required to process CAA according to applicable specifications and their issuance procedures, including handling lookup errors.

DNSSEC can provide authenticated DNS data when validation is correctly deployed across the lookup path, but CAA does not require every domain to use DNSSEC. The security properties of a particular deployment therefore depend on both CAA processing and the DNS controls surrounding the zone.

Administrative security matters as well. An attacker who can modify authoritative DNS may be able to alter CAA policy in addition to other records used by domain-validation methods. CAA should be treated as one layer in domain and certificate control, not as isolation from DNS compromise.

Certificate automation must match the published issuer set

Automated certificate renewal can fail when CAA policy and the configured CA drift apart. This often appears only when a renewal attempt reaches the CA, which can make a stale policy operationally expensive.

A safer change sequence is deliberate:

confirm active issuer
        |
        v
publish intended CAA policy
        |
        v
verify authoritative DNS
        |
        v
exercise issuance or staging path
        |
        v
monitor renewal

During a CA migration, both old and new issuers may need authorization for an overlap period if certificates can still be renewed or issued through either path. Removing the old authorization should follow the actual migration state rather than an assumed cutover date.

The same discipline applies to disaster-recovery issuers. A backup CA that is absent from CAA cannot serve as an immediate fallback until policy permits it and the change is visible according to DNS behavior and CA processing.

The critical flag requires careful handling

CAA records include an issuer-critical flag. When the critical bit is set for a property tag that an issuer does not recognize, the issuer must not issue based on that record set.

This mechanism allows new CAA properties to declare that ignorance is unsafe. It also creates a compatibility requirement: setting the flag on a property without confirming issuer support can intentionally turn lack of support into issuance refusal.

For ordinary issue and issuewild records, operators should follow the syntax and parameters documented by the selected CA rather than inventing values. CA-specific account-binding parameters can further narrow authorization when supported, but their semantics are issuer-specific.

Monitoring should cover policy and actual issuance paths

CAA monitoring is most useful when it compares intended policy with authoritative DNS and the certificate automation that depends on it. A syntactically valid record can still authorize the wrong issuer, omit a required wildcard path, or conflict with a planned CA migration.

Useful checks include the effective CAA record set for production names, the issuer configured in renewal tooling, wildcard requirements, DNS delegation changes, and upcoming certificate renewals.

CAA provides a narrow control with a clear place in the PKI lifecycle. It limits which authorities may create new certificates for a domain under the public issuance process. Keeping that policy aligned with DNS ownership and certificate automation turns the record from passive metadata into an enforceable issuance boundary.

References

Cybersecurity DNS PKI TLS