CAA Records Constrain Public Certificate Issuance at the DNS Boundary

A public certificate can pass every browser check after issuance even if the domain operator never intended to use the certificate authority that created it. The Web PKI has several controls for detecting or responding to bad issuance, but DNS Certification Authority Authorization (CAA) acts earlier: it gives a domain holder a way to state which issuers are permitted to create certificates for a name.

That placement matters. CAA is not a browser trust rule and does not alter certificate path validation. It is an issuance constraint consumed by certificate authorities before they create a certificate. The record therefore sits at a boundary between DNS administration and CA policy enforcement.

The mechanism is compact, but its operational meaning depends on DNS hierarchy, wildcard handling, issuer behavior, and the distinction between restricting an issuer and validating the applicant requesting a certificate.

Issuance policy exists before the certificate

RFC 8659 defines the CAA DNS resource record and the processing rules used by conforming certificate authorities. Before issuing for a domain name, a CA checks the relevant CAA record set. If that record set restricts issuance, the CA cannot issue unless the request is consistent with the published policy or an applicable exception in its certification policy or practice statement permits it.

The common issue property identifies an issuer that the domain holder authorizes. A zone can authorize more than one issuer by publishing multiple CAA records. An issue property with an empty issuer value can request that no issuer create a certificate for the affected name.

This control does not tell a CA that the requester is entitled to the certificate. Domain-control validation and the CA’s other issuance checks still apply. CAA narrows the set of acceptable issuers; it does not replace applicant validation.

That distinction keeps the security boundary precise. A domain operator might authorize one CA for automation and another for a managed enterprise service. Both remain responsible for validating each request under their applicable rules. Publishing their identifiers in DNS grants issuance eligibility, not proof that any particular applicant controls the domain.

The nearest applicable record set controls the name

CAA policy follows DNS naming structure rather than application deployment structure. A CA starts with the requested fully qualified domain name and searches upward through parent labels until it finds a non-empty CAA record set, stopping before the DNS root.

As a result, policy published on a parent can cover descendants that do not publish their own CAA records. A more specific descendant can establish a separate policy by publishing its own record set.

This inheritance is useful for organizations that want a broad issuance boundary across many hostnames, but it also makes delegated DNS ownership significant. A team that can publish CAA at a more specific name may be able to establish an issuance policy different from the parent policy. DNS delegation and certificate governance therefore need compatible ownership boundaries.

Aliases add another implementation detail. RFC 8659 relies on ordinary DNS alias processing during the CAA lookup, while the upward search is performed on the domain being processed. This differs from older CAA processing rules that performed additional tree searches around aliases. Operational checks should reflect the current specification rather than assumptions inherited from RFC 6844.

Wildcard issuance has a separate control

The issuewild property exists because wildcard certificates can carry a different risk profile from certificates for explicit hostnames. When an applicable CAA record set contains issuewild, those properties govern authorization for wildcard names and take precedence over issue properties for that wildcard processing.

For non-wildcard names, issuewild does not grant issuance authority. This permits a domain operator to use one issuer for ordinary names while restricting wildcard certificates to another issuer, or to suppress wildcard issuance while retaining ordinary certificate issuance.

The separation is easy to lose in a DNS inventory that treats every CAA record as equivalent text. Policy review needs to preserve the semantic difference between explicit-name issuance and wildcard issuance. A record set that appears to authorize a CA can produce a different result depending on the certificate names being requested.

Multi-name certificates widen the check. A certificate request can contain several DNS names, and the issuer has to establish CAA authorization for every applicable name in the request. One restrictive name can therefore prevent issuance of a certificate that bundles otherwise permitted names.

CAA narrows issuer choice, not browser trust

CAA and Certificate Transparency occupy different points in the certificate lifecycle. CAA is evaluated by an issuer before issuance. Certificate Transparency records public certificate activity so that domain operators and other parties can observe certificates after they have been issued.

Neither mechanism turns the other into a substitute. A correctly enforced CAA policy can reduce exposure to issuance through an unapproved CA, but it cannot prevent an authorized CA from issuing a bad certificate. RFC 8659 explicitly treats mis-issuance by an authorized CA as outside the protection CAA provides.

Likewise, a certificate that violates a domain’s CAA policy does not automatically become cryptographically invalid to a TLS client. Client trust decisions are based on certificate validation rules and platform policy, not a fresh CAA lookup performed by the browser for each connection.

This separation has an operational consequence: CAA is preventive policy for participating issuers, while certificate monitoring remains useful for detecting issuance that policy did not stop. Organizations that treat CAA as a complete certificate-control system leave gaps around authorized issuers, DNS compromise, policy mistakes, and ecosystem non-compliance.

DNS integrity becomes part of issuance control

Publishing issuance policy in DNS gives DNS administration direct influence over certificate issuance. If an attacker can alter authoritative DNS data, that attacker may be able to change CAA policy as part of a broader domain compromise. If DNS responses can be suppressed or spoofed during CA processing, the issuer may receive a policy view that differs from the domain operator’s intent.

RFC 8659 strongly recommends DNSSEC for authenticating CAA records but does not require domains to sign them. It also states that an issuer must not issue in conflict with the relevant CAA record set regardless of whether that DNS data is signed.

DNSSEC can provide authenticated denial of existence, which is particularly relevant when the security question is not merely what a record says but whether a restrictive record was removed from the response. Without DNSSEC, issuers need other DNS security controls to reduce spoofing and suppression risk.

CAA therefore inherits the operational quality of the DNS control plane around it. Access control for zone changes, registrar security, delegation management, DNSSEC operations where deployed, and change auditing all affect the reliability of the issuance boundary.

Critical properties can fail closed

CAA records contain a flags field. RFC 8659 defines an issuer-critical flag for properties whose semantics must be supported for safe processing. If a relevant record set contains an unknown or unsupported property marked critical, a conforming CA must not issue for the affected name.

The flag provides an extension mechanism that can fail closed when new policy semantics matter. It also creates an availability risk if a critical property is published incorrectly or before intended issuers support it. Certificate issuance can stop even though DNS resolution and existing TLS service remain healthy.

That behavior makes CAA changes operationally closer to security-policy changes than ordinary descriptive DNS metadata. A syntax-valid record can still have consequences that appear only during a later renewal attempt.

Automated certificate renewal makes this timing especially relevant. A restrictive change may sit unnoticed until the next issuance transaction. Monitoring only current certificate expiry dates is not enough; policy changes and renewal compatibility belong in the same operational view.

Issuer restrictions need lifecycle ownership

CAA is most effective when its records represent actual certificate operations rather than an aspirational list of preferred providers. An organization that changes CA vendors, introduces a second issuance service, or separates wildcard issuance needs to update DNS policy in coordination with those changes.

Stale authorization also matters. Leaving an old CA authorized after migration preserves an issuance path that the organization may no longer monitor or expect. The record does not create an immediate vulnerability by itself, since the old issuer must still perform its validation process, but it weakens the intended reduction in issuer surface.

The inverse failure is more visible: removing a required issuer too early can block renewal. Short certificate lifetimes and automated issuance compress the time available to notice that policy and automation disagree.

A durable CAA deployment therefore has two properties. Its DNS records encode a deliberately narrow issuer set, and its ownership process keeps that set aligned with real issuance paths. The technical record is small; the security value comes from maintaining the boundary as certificate infrastructure changes.