# Publish CAA only after mapping every legitimate certificate issuer > Use DNS Certification Authority Authorization records to express issuance policy without disrupting approved certificate workflows. - Canonical URL: https://update.dsesecurity.com/updates/publish-caa-after-mapping-certificate-issuers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:48+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## 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. ## Article 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](https://www.rfc-editor.org/rfc/rfc8659.html) 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 - [IETF RFC 8659](https://www.rfc-editor.org/rfc/rfc8659.html) ## Primary reference - Name: RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8659.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Publish CAA only after mapping every legitimate certificate issuer,” DSE Security, https://update.dsesecurity.com/updates/publish-caa-after-mapping-certificate-issuers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.