CAA Records Constrain Certificate Authority Issuance

A certificate authority can validate control of a domain and still face a separate policy question: is this CA authorized by the domain operator to issue for that name? Certification Authority Authorization, or CAA, gives the DNS namespace a record type for expressing that constraint.

CAA operates before certificate issuance. A participating public CA checks the relevant DNS CAA policy and evaluates whether its issuer identity is authorized. The mechanism does not make a certificate trusted, revoke an existing certificate, or tell a browser to reject a certificate after issuance. It narrows the set of issuers that should create new certificates for the domain.

A CAA record carries flags, a tag, and a value

A CAA resource record has three logical fields: flags, property tag, and property value. A simple policy can authorize one CA with an issue property:

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

The value identifies the CA according to the issuer’s documented CAA identifier. It is not a generic URL and should not be guessed from a company name.

Several CAA records can coexist at the same owner name. Their meaning depends on the property tags and values rather than DNS record order.

The flag octet also contains the issuer-critical bit. When that bit is set on a property whose tag a CA does not recognize, the CA must not proceed as though the unknown property were harmless. This permits future CAA properties to declare that issuer support is required for safe processing.

issue and issuewild cover different issuance cases

The issue property authorizes certificate issuance for the domain under the CAA processing rules. The issuewild property provides a separate authorization path for certificates that contain a wildcard DNS identifier.

For example:

example.com.  CAA 0 issue "ca-a.example"
example.com.  CAA 0 issuewild "ca-b.example"

This policy can direct ordinary issuance and wildcard issuance to different CAs.

An empty issuer value can explicitly deny the corresponding class of issuance:

example.com.  CAA 0 issue ";"

That form is useful when a domain operator wants CAA policy to authorize no CA for the affected issuance class. Operational tooling should preserve the exact syntax expected by the CAA specification and the selected CA rather than rewriting values casually.

Policy lookup can inherit from a parent domain

CAA processing does not require every hostname to publish its own record. The lookup procedure can search upward through the DNS name hierarchy until it finds the applicable CAA record set, subject to the protocol’s alias-processing rules.

That makes a policy at a parent name useful for many descendants:

example.com
├── api.example.com
├── shop.example.com
└── static.example.com

If a descendant has no more specific applicable CAA policy, the parent policy can govern issuance for it. A descendant that publishes its own applicable CAA record set changes the policy boundary for that name.

This inheritance has an operational consequence: adding a CAA record to one subdomain is not merely additive to a parent set. The effective record set at the relevant lookup point is what matters. DNS changes should therefore be reviewed against the complete name hierarchy used for certificate requests.

CAA constrains issuers, not domain-control validation

CAA and domain-control validation solve different problems. A CA still needs the validation required for the certificate it intends to issue. CAA adds an authorization check about the issuer.

Conceptually:

domain-control validation -> may the requester control the identifier?
CAA evaluation            -> may this CA issue for the identifier?
certificate policy        -> do the remaining issuance requirements pass?

A successful DNS or HTTP validation challenge does not erase a restrictive CAA policy. Conversely, an authorized CAA entry does not prove that the certificate requester controls the domain.

Keeping these checks separate matters during incident analysis. A failed issuance can come from validation, CAA policy, account policy, rate controls, or another CA requirement; changing CAA is appropriate only when CAA is the failing boundary.

CAA is not certificate revocation

Changing a CAA record affects subsequent issuance decisions. It does not invalidate certificates that were already issued.

Suppose a domain moves from one CA to another:

before: CAA 0 issue "ca-a.example"
after:  CAA 0 issue "ca-b.example"

Certificates previously issued by CA A do not become revoked because the DNS policy changed. Their validity and revocation status remain governed by the certificate ecosystem’s other mechanisms.

This distinction is important during CA migration. Operators need to manage both the future issuance policy and the lifecycle of certificates already deployed.

DNS integrity remains part of the security boundary

CAA policy is retrieved through DNS, so the integrity of the DNS path matters. CAA itself does not cryptographically authenticate DNS data. DNSSEC can provide authenticated DNS data when the zone, resolver path, and validation behavior are configured accordingly.

Even without DNSSEC, CAA still establishes an issuance policy that compliant CAs are expected to process. It should not be described as protection against every DNS attacker. If an attacker can alter the DNS answers a CA relies on, the security assumptions around policy retrieval have changed.

Operators should also account for ordinary DNS behavior such as TTLs, delegation, aliases, and propagation when changing CAA. A policy edit made immediately before certificate renewal can produce different observations across resolvers until cached data expires.

iodef is for reporting, not issuer authorization

CAA also defines the iodef property for reporting certificate requests or policy violations through a specified contact mechanism. It does not authorize a CA to issue.

A record set can therefore contain both authorization and reporting properties:

example.com.  CAA 0 issue "ca.example"
example.com.  CAA 0 iodef "mailto:security@example.com"

The first line participates in issuer authorization. The second supplies a reporting destination under the applicable CAA rules.

A reporting address should be treated as operational input. Publishing it does not guarantee that every event will generate a message, and it does not replace certificate inventory or Certificate Transparency monitoring.

CAA and Certificate Transparency cover different stages

CAA is preventive policy at issuance time. Certificate Transparency records evidence associated with certificate issuance in public logs. The two controls are complementary.

CAA -> constrain permitted issuers before issuance
CT  -> expose logged issuance for observation and audit

A restrictive CAA policy can reduce the set of CAs authorized to issue, while CT monitoring can surface certificates that appear in public logs. Neither mechanism replaces certificate path validation, revocation handling, or CA account security.

This separation also gives operators a cleaner response model. CAA expresses intended issuer policy; CT observations can be compared with that intent. An unexpected certificate still requires investigation because the record alone does not establish the cause of issuance.

Issuance policy needs maintenance

CAA is small enough to look like a set-and-forget DNS record, but certificate operations change. Teams switch CAs, add wildcard certificates, delegate services, introduce managed platforms, and retire old issuance accounts.

A stale CAA policy can block legitimate renewals. An overly broad policy can leave issuers authorized after the operational need has disappeared. Changes should be tied to certificate inventory and renewal ownership so DNS policy follows the actual issuance architecture.

The useful boundary is precise: CAA publishes which issuers are permitted to create new certificates for a DNS name under the protocol’s processing rules. It does not replace the rest of PKI. Used with disciplined DNS administration, certificate inventory, and issuance monitoring, it turns issuer choice from an implicit assumption into an explicit domain policy.