CAA and DNS Chain of Trust Strategy: Controlling Who Issues Your Certificates

There are hundreds of publicly trusted certificate authorities in the world. Without intervention, any one of them can issue a valid certificate for your domain, provided they can complete domain validation. That's the default. Open by default.

Certificate Authority Authorization — a DNS record type that specifies which CAs are permitted to issue certificates for your domain — changes that default. It's been mandatory for CAs to check since September 2017, following CA/Browser Forum Ballot 187. It takes five minutes to configure. It costs nothing.

Yet as of mid-2024, only about 15-16% of the top 150,000 TLS-supporting websites had CAA records in place, according to Qualys SSL Labs data. More recent surveys in 2025 show adoption has barely moved. CAA remains one of the cheapest, most effective security controls in PKI, and the vast majority of organisations haven't implemented it.

This page is about why that matters — and why CAA alone isn't enough.

CAA: The Five-Minute Control That Blocks Mis-Issuance

A CAA record is a DNS resource record (type 257) that tells certificate authorities which of them are authorised to issue certificates for your domain. The record contains three elements: a flag, a tag, and a value. The tag specifies the type of rule — issue for standard certificates, issuewild for wildcard certificates, and iodef for violation reporting.

The mechanics are simple. When a CA receives a certificate request for your domain, it queries DNS for CAA records. If CAA records exist and the CA isn't listed, the CA must refuse issuance. If no CAA records exist, any CA may proceed. The iodef tag allows you to specify an email address or endpoint where CAs should report issuance attempts that violate your CAA policy — though not all CAs send these reports reliably.

CAA records use hierarchical inheritance. A record on example.com automatically applies to all subdomains. You can override this by placing a more specific CAA record on a subdomain, allowing different CAs for different parts of your infrastructure. This flexibility matters for large organisations where different teams may use different CAs for legitimate reasons.

The RFC 8657 extensions add even more specificity. The accounturi parameter lets you bind issuance not just to a CA, but to a specific ACME account at that CA. The validationmethods parameter lets you specify which domain validation methods are acceptable. These parameters are particularly valuable for organisations with mature ACME automation — they ensure that only your automation, using your specific account, can trigger certificate issuance.

So why is adoption so low? Three reasons. First, awareness: many security teams simply don't know CAA exists or what it does. Second, DNS management friction: in organisations where DNS is managed by a separate team, adding records requires a change request and often a longer approval cycle than the actual configuration work. Third, fear of breakage: teams worry that an incorrect CAA record will prevent legitimate certificate issuance, and since the failure mode is "your renewal silently fails," the perceived risk outweighs the perceived benefit.

The third concern is legitimate but manageable. Start by auditing which CAs currently issue for your domains — CT logs make this trivial. Configure CAA records to match your current state. Then tighten.

The DNS Dependency Most Certificate Strategies Ignore

CAA records are enforced through DNS. Domain validation — the process by which a CA confirms you control a domain before issuing a certificate — is also performed through DNS (or HTTP, or email, but DNS-based validation is the most common automated method). Your entire public certificate issuance chain runs through DNS.

This creates a dependency that most certificate strategies don't acknowledge: if an attacker can compromise or manipulate your DNS, your CAA records are worthless and your domain validation is exploitable.

The attack scenarios are well-documented. BGP hijacking can redirect DNS queries to attacker-controlled resolvers, allowing them to respond to domain validation challenges and bypass CAA checks simultaneously. Registrar compromise gives attackers direct control over DNS records — they can modify or delete CAA records and add validation records at will. Dangling CNAME records pointing to decommissioned services can be claimed by attackers, who can then pass domain validation for those subdomains.

CSC's Domain Security Report 2026 found that 24% of survey participants experienced a domain-security-related incident in 2024 — one in four organisations. In that same report, 88% of registered web domains that resemble Global 2000 brands (homoglyphs) are owned by third parties. DNS is not the stable foundation most organisations assume it to be.

The strategic implication is clear: a certificate strategy that treats DNS as reliable plumbing is built on sand. DNS security is a prerequisite for certificate security.

DNSSEC: The Uncomfortable Conversation

DNSSEC — Domain Name System Security Extensions — adds cryptographic authentication to DNS responses. It allows resolvers to verify that DNS data hasn't been tampered with in transit. In the context of certificate issuance, DNSSEC protects the integrity of CAA records and DNS-based domain validation.

The case for DNSSEC is straightforward. Without it, DNS responses can be spoofed or modified by anyone positioned between the resolver and the authoritative nameserver. With it, any modification is detectable.

The case against DNSSEC is operational. Deployment introduces key management complexity — zone signing keys need rotation, key rollovers can cause outages if mishandled, and troubleshooting DNSSEC failures requires specialist knowledge that many DNS operations teams lack. Some European ccTLDs like .se, .no, and .dk have pushed DNSSEC signing rates above 50-75%, but global adoption remains low — single digits to low teens depending on measurement methodology.

The CA/Browser Forum is tightening the connection between DNSSEC and certificate issuance. Recent ballots require CAs to deploy DNSSEC validation on DNS queries associated with CAA record lookups from primary network perspectives, effective March 2026 for both TLS and S/MIME baseline requirements. This means CAs themselves will increasingly rely on DNSSEC to validate CAA records — making DNSSEC deployment on your zones more operationally relevant.

The honest strategic recommendation: DNSSEC is worth deploying for zones that host CAA records and are used for DNS-based domain validation, particularly if you operate in a regulated industry or manage high-value domains. For internal zones or low-risk domains, the operational overhead may not justify the protection. This is a risk-based decision, not a one-size-fits-all mandate.

DNS Compromise Scenarios and Certificate Impact

Understanding how DNS compromise translates to certificate compromise helps organisations prioritise DNS security investments within their certificate strategy.

Registrar compromise is the highest-impact scenario. An attacker who gains access to your domain registrar account can modify nameserver delegations, edit DNS records directly, transfer domains, and disable security features. From there, they can delete CAA records, add their own validation records, obtain certificates from any CA, and use those certificates to intercept traffic — all before you detect the compromise. The MyEtherWallet incident in 2018, where BGP hijacking redirected traffic to a phishing clone, resulted in over $150,000 in stolen Ethereum within hours.

Dangling DNS records are a more subtle risk. When a CNAME record points to a cloud service that's been decommissioned, an attacker can claim that service endpoint and inherit DNS resolution for your subdomain. This enables them to pass HTTP-based domain validation and obtain a certificate for your subdomain. The fix is simple — audit and remove stale DNS records — but the prevalence of this issue across large enterprises suggests it's not being done systematically.

DNS cache poisoning, while harder to execute against modern resolvers, remains a viable attack vector in environments where DNSSEC is not deployed. An attacker who can poison a resolver's cache can redirect validation queries and bypass CAA checks simultaneously.

Integrating DNS Trust Into Your Certificate Strategy

A certificate strategy that accounts for DNS trust has four components.

First, deploy CAA records for all domains. Start with your current CA list, add iodef for reporting, and use issuewild to restrict wildcard issuance separately. This takes hours, not weeks.

Second, secure your registrar accounts. Enable multi-factor authentication, implement registry lock for your most valuable domains (CSC's research shows registry lock adoption is over six times higher among enterprises using enterprise-class registrars versus consumer-grade ones), and audit registrar access regularly.

Third, assess DNSSEC deployment. Prioritise zones used for public certificate issuance and DNS-based domain validation. Use your DNS provider's managed DNSSEC if available — it dramatically reduces operational complexity.

Fourth, integrate DNS monitoring with certificate transparency monitoring. CT logs tell you when a certificate was issued. DNS monitoring tells you if the conditions that enabled issuance were legitimate. Together, they provide a complete picture: CAA prevents mis-issuance at the policy level, CT detects it at the audit level, and DNS monitoring identifies the infrastructure compromise that might have enabled it.

This layered approach — CAA plus CT plus DNS security — is what a mature certificate trust strategy looks like. Each layer is simple individually. The strategic value is in combining them.

Sector context: private PKI and regulated trust boundaries in financial services, healthcare, and manufacturing & OT.

---

← Back to Certificate Strategy: The Framework Most Organisations Skip

External References

• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — ietf.org
• RFC 8657: CAA accounturi and validationmethods Parameters — ietf.org
• CA/Browser Forum Ballot 187: CAA Checking (2017)
• CSC Domain Security Report 2026 — cscdbs.com
• CAA Record Adoption Survey (Qualys SSL Labs, June 2024) — ~15.4% adoption among top 150,000 sites
• dns-caa-catalog: Open-Source CAA Record Survey — github.com/UnitVectorY-Labs/dns-caa-catalog
• SANS ISC: Quick Status of CAA DNS Record Adoption — isc.sans.edu