DNS CAA Narrows Certificate Authority Issuance

Public certificate issuance depends on a certificate authority validating control of the requested domain name. DNS Certification Authority Authorization (CAA) adds a separate policy signal: a domain can publish which certificate authorities are permitted to issue for that name.

CAA does not replace domain-control validation, prove that a requester is legitimate, or protect a private key. Its role is narrower. A conforming public certificate authority checks the applicable CAA policy before issuance and must not issue when that policy forbids it.

That distinction makes CAA useful as a boundary around the public CA ecosystem. A domain that relies on a small set of certificate authorities can express that choice in DNS instead of leaving issuance open to every CA that could otherwise validate the name.

CAA records express issuance permission

A basic record has a flags field, a property tag, and a value:

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

The issue property authorizes the identified certificate authority to issue certificates for the domain under the applicable CAA rules. Multiple issue records are additive: each authorized CA can be listed separately.

CAA policy is not a request to issue a certificate. It only states which issuers are acceptable. The CA must still perform the validation and policy checks required for the certificate request.

A restrictive deployment can publish only the CA identifiers that its certificate automation actually uses. That reduces the set of public CAs that may issue for the domain, but it does not prevent an authorized CA from issuing after its normal validation succeeds.

issuewild separates wildcard policy

Wildcard certificates can have a distinct authorization policy through the issuewild property:

example.com.  CAA 0 issue "ca.example"
example.com.  CAA 0 issuewild "wildcard-ca.example"

When applicable issuewild records exist, they govern wildcard issuance. This permits an organization to route ordinary and wildcard certificates through different certificate authorities.

The distinction matters in environments where wildcard issuance has tighter operational controls. For example, a team may use one CA for routine host certificates while reserving wildcard issuance for a separate automation path.

A CAA configuration should therefore be checked against the actual certificate inventory. Treating issue and issuewild as interchangeable can create either unintended authorization or failed renewals.

Policy lookup can inherit from a parent name

CAA processing searches for the applicable policy according to DNS and CAA lookup rules. A record at a parent domain can therefore affect names below it when no closer applicable CAA policy overrides that result.

This makes a high-level record useful for establishing a default issuance boundary across many subdomains. It also creates an operational dependency: a subdomain team may be constrained by policy published higher in the namespace.

Consider a service at api.example.com. If that name has no closer applicable CAA policy, the CA can encounter policy inherited from example.com. If the service later moves to certificate automation using another CA, issuance can fail until the DNS policy and automation are aligned.

CAA lookup also interacts with aliases. DNS architecture should be reviewed as a whole rather than assuming that the record visible at the requested hostname is the only data relevant to the CA’s decision.

CAA is a DNS policy, so DNS integrity still matters

CAA inherits the security properties of the DNS path used to retrieve it. Publishing restrictive records does not make DNS itself tamper-proof.

DNSSEC can provide authenticated DNS data when the relevant zones and validating path are correctly configured. Without that protection, CAA still serves its standardized issuance-policy role, but it should not be described as a cryptographic proof that the returned policy is authentic.

Operational reliability matters as well. A broken authoritative DNS service can interfere with CAA processing and certificate issuance. Certificate renewal therefore depends not only on ACME or another issuance protocol, but also on the availability and correctness of the DNS data used by the CA.

This coupling is a reason to treat CAA changes as production changes. DNS syntax, delegation, DNSSEC state, aliases, and certificate automation all belong in the same review.

The critical flag changes handling of unknown properties

CAA defines an issuer-critical flag bit. A record with that bit set tells a CA that an unrecognized property cannot simply be ignored.

The mechanism supports stricter handling of future or private CAA properties, but it also raises the cost of configuration mistakes. Setting the critical bit on a property that the intended CA does not support can stop issuance.

For common issue and issuewild deployments, the flags value is normally 0:

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

A nonzero flags value should be intentional and tied to the semantics of the property in use. Copying a critical flag from an unrelated example can turn an advisory-looking DNS edit into an issuance outage.

CAA does not revoke existing certificates

Changing CAA affects authorization for certificate issuance under the CA’s required checks. It does not revoke a certificate that was already issued.

If an existing certificate or private key must no longer be trusted, the response belongs to certificate revocation, key replacement, service configuration, and incident handling as appropriate. Tightening CAA can reduce future issuance options, but it does not erase previously issued credentials.

The same boundary applies after an unauthorized issuance event. Correcting CAA is useful for future policy, while the affected certificate requires its own response path.

Certificate automation must stay aligned with DNS policy

CAA is easy to deploy incorrectly when certificate ownership is fragmented. A central DNS team may publish a narrow CA list while application teams use managed platforms that obtain certificates through different issuers.

A practical rollout starts from the issuance paths already in use. Map each public hostname to its certificate authority, distinguish wildcard from non-wildcard certificates, identify delegated subdomains and aliases, then compare that inventory with the proposed CAA records.

Renewal deserves special attention. A certificate can remain valid for weeks or months after a CAA mistake is introduced, so the first visible failure may occur much later during automated renewal. Monitoring should therefore cover issuance and renewal failures rather than relying on the current certificate’s validity as evidence that policy is correct.

Changes to hosting, CDN, ingress, or managed certificate services should include a CAA review whenever the certificate authority can change.

CAA narrows one layer of PKI authority

CAA is most precise when treated as an issuance constraint, not as a general TLS defense. It cannot secure a compromised origin server, detect a stolen private key, validate application identity, or replace certificate transparency monitoring.

Its value is the smaller decision it makes explicit: which certificate authorities may issue for a DNS name. That policy can reduce unnecessary issuer exposure and make certificate automation more deliberate, provided the DNS configuration remains synchronized with the systems that request and renew certificates.

References

Cybersecurity PKI DNS TLS Certificates