DNS CAA Narrows Which CAs May Issue Certificates

A publicly trusted certificate authority can issue a certificate only after completing the validation required by its policy and the applicable ecosystem rules. DNS Certification Authority Authorization (CAA) adds another control: a domain can publish which CAs are authorized to issue certificates for that DNS namespace.

CAA does not replace domain-control validation, certificate transparency, or certificate verification by clients. It constrains issuance at the CA side. A CA processing a request checks the relevant CAA policy before issuance and must not issue when the policy forbids it.

certificate request
        |
        v
CA resolves CAA policy
        |
        +--> authorized ----> other validation ----> issuance may proceed
        |
        +--> not authorized -----------------------> no issuance

The control is useful because the Web PKI contains many trusted issuers. A domain that intends to use only a selected CA can express that choice in DNS rather than leaving every otherwise trusted CA equally eligible to issue for the name.

CAA records carry issuer policy

RFC 8659 defines the CAA DNS resource record. A record contains flags, a property tag, and a property value. The issue property authorizes certificate issuance for the domain.

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

The value identifies the authorized issuer according to the CA’s registered issuer-domain-name. The example is illustrative; a deployment must use the identifier documented by its actual CA.

Multiple issue records can authorize multiple CAs:

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

CAA is therefore an allowlist mechanism rather than a ranking mechanism. Publishing two authorized issuers does not state a preference between them.

A domain can also explicitly deny ordinary issuance with an empty issuer value:

example.com.  CAA 0 issue ";"

This form states that no CA is authorized by the issue property for the domain. Operational changes must account for that policy before a renewal or replacement certificate is requested.

Wildcard authorization has a separate property

The issuewild property controls authorization for wildcard certificate issuance. If a relevant CAA RRset contains issuewild, those records govern wildcard requests instead of issue records.

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

In this policy, ordinary issuance and wildcard issuance can be delegated to different CAs. That distinction matters for environments that permit routine host certificates but route wildcard certificates through a narrower issuance process.

If no issuewild property is present in the applicable RRset, the issue property also controls wildcard issuance. Adding issuewild therefore changes the authorization boundary specifically for wildcard requests.

Policy can be inherited from a parent name

CAA processing does not stop at the exact requested name when no CAA policy is found there. The lookup procedure can move upward through the DNS hierarchy until it finds an applicable CAA RRset, subject to the rules in RFC 8659.

A parent domain can consequently establish issuance policy that covers names below it when those names do not publish a closer applicable policy.

service.dev.example.com
        |
        | no applicable CAA here
        v
dev.example.com
        |
        | no applicable CAA here
        v
example.com
        |
        +--> CAA policy found

A child name can publish its own CAA RRset when it needs a different issuer set. This makes DNS ownership and certificate issuance policy closely related: adding a delegated or independently managed namespace can also change where CAA policy needs to live.

CNAME and DNAME processing add further resolution rules. Certificate automation should rely on standards-conforming CAA resolution rather than implementing a simple exact-name TXT-style lookup.

The critical flag affects unknown properties

The flags octet includes an issuer-critical bit. When that bit is set on a property a CA does not recognize, the CA must not issue on the basis of that CAA RRset.

example.com.  CAA 128 custom-property "value"

That mechanism permits a domain to mark an extension property as mandatory for issuers. It also creates an operational hazard: setting the critical bit on a property unsupported by the intended CA can block issuance.

For the standardized issue, issuewild, and iodef properties, deployments should still follow the syntax and semantics defined by the standard and the CA’s documented issuer identifiers. The critical flag is not a substitute for correct property values.

iodef provides a reporting contact

The iodef property can publish a contact URI for reporting CAA-related policy violations or issuance-request exceptions.

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

The presence of iodef does not itself authorize or prohibit issuance. It provides reporting information. A domain that needs issuer restrictions still requires issue or issuewild policy as appropriate.

Reporting behavior also depends on issuer support and circumstances. An iodef record should not be treated as a guaranteed alerting channel or as a replacement for certificate inventory and Certificate Transparency monitoring.

CAA constrains CAs, not certificate use

CAA is evaluated around issuance. Browsers and TLS clients do not use a domain’s current CAA records to decide whether an already issued certificate is valid. Removing a CA from CAA therefore does not revoke certificates that CA previously issued.

That boundary separates several controls that are sometimes grouped together:

  • CAA expresses which CAs may issue.
  • CA validation establishes whether an issuance request satisfies required validation.
  • Certificate Transparency creates public logging evidence for certificates covered by browser ecosystem policy.
  • Revocation mechanisms communicate status for certificates after issuance.
  • TLS clients validate the certificate presented during a connection.

No single item replaces the others. CAA reduces the set of authorized issuers, but it does not make an authorized CA infallible and does not guarantee that unauthorized issuance is technically impossible.

DNS operations become part of certificate operations

A restrictive CAA policy can block legitimate issuance when DNS and certificate automation drift apart. CA migrations, backup issuers, wildcard workflows, delegated subdomains, and emergency replacement procedures all need to match the published records.

Before tightening policy, operators can inventory the CAs actually used by active issuance paths, map wildcard and non-wildcard flows separately, and verify the issuer identifiers required by each CA. DNS changes also need enough time to propagate according to normal resolver and cache behavior before dependent issuance workflows assume the new policy is visible.

CAA is strongest as a narrow authorization layer with a precise operational owner. It gives a domain a standards-based way to reduce issuer choice at certificate issuance time while leaving certificate validation, logging, revocation, and TLS enforcement to their respective mechanisms.

Cybersecurity PKI DNS TLS CAA