Certification Authority Authorization records let a domain holder state which certificate authorities may issue certificates for the domain. They are useful only when the record matches the real renewal path and the operator understands how policy can be inherited from parent names.

Inspect the current policy

Query the exact hostname and its parent names:

for name in www.example.test example.test test; do
  printf '== %s\n' "$name"
  dig +noall +answer CAA "$name"
done

An empty answer at the leaf does not necessarily mean there is no applicable policy. CAA processing can continue upward according to the DNS rules. Use an authoritative answer when diagnosing a change and compare it with at least one recursive resolver.

Match the account’s issuer identifier

A record uses tags such as issue or issuewild and an issuer-domain value:

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

The value is an authorization identifier, not the display name from a certificate. Confirm it in the certificate authority’s current documentation. Wildcard authorization may require a separate issuewild policy.

Stage the DNS change before renewal

Add or tighten CAA while the current certificate is healthy. Wait through the previous TTL, query authoritative and recursive answers, and run a staging or renewal test supported by the ACME client. Keep a rollback record ready.

Do not add a restrictive record during an expiry incident unless the issuer path has already been verified. A syntactically correct but wrong policy can turn automatic renewal into a hard failure.

Observe issuance failures

CAA checks happen at issuance time, not on every HTTPS request. Certificate monitoring must therefore cover both current expiry and renewal attempts. Log the effective DNS answer with the ACME failure instead of recording only a generic authorization error.

Sources