What you need to know
Use DNS Certification Authority Authorization records to express issuance policy without disrupting approved certificate workflows.
Potentially affected
Public DNS names for which one or more certification authorities issue publicly trusted certificates
DSE recommendation
Inventory direct and delegated issuance paths, publish a tested CAA policy, and monitor both DNS and certificate issuance changes.
CAA records can narrow which public certification authorities are authorized to issue for a domain, but an incomplete issuer inventory can block a legitimate renewal. Treat CAA as a managed issuance policy with owners and tests, not a one-time DNS hardening entry.
Source fact:
IETF RFC 8659 defines the DNS Certification Authority Authorization resource record. A domain holder can use CAA properties to identify certification authorities authorized to issue certificates for the domain and can provide an incident-reporting contact. The specification describes how a certification authority finds the relevant CAA record set, including processing across DNS names and aliases.
A compliant public certification authority evaluates the applicable policy before issuance. The record expresses current authorization; it is not used by browsers or other relying parties to decide whether an already issued certificate is valid. The RFC also notes that CAA does not prevent an authorized authority from mis-issuing and that DNSSEC can protect record authenticity but is not a prerequisite for using CAA.
Boundary
CAA enforcement depends on the issuing authority and the certificate context. It does not inventory certificates, revoke existing certificates, validate private-PKI workflows, or replace account security at the authority. DNS delegation, CNAMEs, parent-domain policy, issuer-specific parameters, and automation vendors can alter the applicable record set. The correct value must come from the selected authority’s current documentation, not a guessed brand name.
Applicability questions
- Which internal teams, hosting providers, CDNs, managed services, and emergency processes request public certificates?
- Which issuer identifiers and parameters do those authorities currently require?
- Do wildcard issuance and ordinary issuance need different authorization?
- How do aliases, delegated subdomains, and acquired domains affect policy discovery?
- Is there a controlled emergency path for adding an approved issuer before a renewal deadline?
DSE recommendation:
Build an issuance map from certificate-transparency monitoring, certificate-manager inventories, DNS zones, procurement records, and service-owner interviews. Confirm each issuer’s official CAA identifier and any account-binding parameter. Include certificates obtained indirectly by SaaS, CDN, and domain-validation automation.
Model the record lookup for representative names, then publish to a noncritical delegated name and complete real issuance and renewal tests. Introduce production records in stages with normal DNS change control. Assign ownership for additions, removals, incident contact handling, and acquisitions. Monitor CAA answers from external resolvers and alert on unexpected record changes or public certificates from an unapproved authority.
Verification and evidence
Retain the approved issuer map, authority documentation, zone changes, DNS responses with timestamps, issuance and renewal results, and certificate-transparency alerts. Test a permitted workflow and, where the authority offers a safe validation method, confirm that a nonpermitted issuer is rejected without ordering an unnecessary certificate. Review the map before removing an issuer and before large renewal windows.
Official references
Review the official source
RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record · Verified August 25, 2026
Need help applying this guidance safely?
DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.
Talk with DSE