# CAA DNS Records and PQC **Source**: https://quantumsequrity.com/blog/caa-records-pqc **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # CAA DNS Records and PQC 10 min read CAA stands for Certification Authority Authorization. It is a small but powerful DNS feature that lets a domain owner say which Certificate Authorities are allowed to issue certificates for that domain. If you own example.com and you publish a CAA record naming Let's Encrypt as your only authorized CA, then any other CA that follows the rules must refuse to issue a cert for your domain. CAA was meant to stop a specific type of attack: a malicious or sloppy CA issuing a certificate for a domain to someone who does not own it. With post-quantum cryptography arriving, CAA is becoming relevant in a new way. The next phase of the protocol's evolution is letting domain owners specify not just which CA can issue, but which cryptographic algorithms they want in those certificates. ## What CAA Does Today RFC 8659 is the modern specification for CAA. The record is a small DNS entry that looks like this in zone file format: example.com. CAA 0 issue "letsencrypt.org" That single line tells every CA that follows the rules: only Let's Encrypt may issue an end-entity certificate for example.com or any subdomain. If GlobalSign tries, GlobalSign must say no. If a typo somewhere in DigiCert's automation tries to issue a cert, DigiCert's compliance check must catch it before the cert goes out. There are three property tags that CAA supports. The "issue" tag covers normal end-entity certificates. The "issuewild" tag covers wildcard certificates, which are higher risk because they cover any subdomain. The "iodef" tag tells a CA where to email a notification if it sees a request that violates the policy. This system is a baseline of the public Web PKI. The CA/Browser Forum requires CAA checking as part of its baseline requirements. A CA that ignores CAA can lose its ability to issue trusted certificates. The system is enforced not by network controls but by audits and trust store removal, which is a softer but ultimately effective discipline. ## Why CAA Matters for the PQC Transition The reason CAA is interesting in the post-quantum context is simple. As CAs roll out new algorithms, domain owners need a way to say which algorithms they are willing to accept in certificates for their domain. A site that holds long-lived sensitive data may want to refuse classical-only certificates and demand a hybrid or pure post-quantum certificate. A site running on legacy embedded clients may want to refuse pure post-quantum certificates because the client cannot validate them. Today CAA does not have a property for "only issue ML-DSA" or "do not issue with ECDSA". The IETF discussions are exploring how that property should look, what its grammar should be, and how CAs should enforce it. For background on why post-quantum signatures are coming, see [why-rsa-2048-will-break](why-rsa-2048-will-break.md). ## PQC-Specific CAA Extensions The most discussed proposal would add a parameter to existing CAA tags. The idea is to let an operator say something like: example.com. CAA 0 issue "letsencrypt.org; algorithm=ml-dsa-65" The CA reading this record would interpret it as: Let's Encrypt may issue, but only if the leaf certificate is signed with ML-DSA-65 or stronger. If the operator wants either classical or post-quantum, they can list multiple algorithms or omit the parameter entirely. A second class of proposals deals with hybrid signatures. A hybrid certificate is signed twice, once with a classical algorithm and once with a post-quantum algorithm. The operator may want to require both, or only the post-quantum one, or only the classical one. The grammar of the parameter has to express that choice cleanly. For more on hybrid certificates, see [hybrid-encryption](hybrid-encryption.md). The third area is key strength. In the classical world, CAA does not say anything about key sizes. There is nothing stopping a CA from issuing an RSA-2048 cert when the operator wanted RSA-4096. The PQC parameter sets formalize key strength more rigorously, since ML-DSA-44 and ML-DSA-87 have specific security claims attached. Allowing the operator to say "minimum security level 3" gives them a clearer policy lever. ## How DNS Delegation Complicates Things DNS delegation is the hardest part of any CAA conversation. CAA records are checked at the apex domain, but they apply to subdomains. If you set a CAA record on example.com, it applies by inheritance to www.example.com and api.example.com unless those subdomains have their own records. This becomes interesting in the PQC world for several reasons. A large enterprise often delegates subdomains to different teams, each with different security postures. The marketing team running marketing.example.com might be fine with any modern certificate. The api team running api.example.com might want post-quantum strength because the API holds sensitive data with a long protection horizon. If the apex CAA record says "only ML-DSA", then the marketing subdomain inherits that policy and may have trouble getting a certificate from a CA that only supports classical algorithms. If the apex CAA record is permissive and the api subdomain has a stricter local CAA record, then the api subdomain is properly protected but the marketing site can still get any certificate. The delegation question gets harder at the registrar level. Some registrars do not allow CAA records on subdomains. Some DNS hosting providers do not support DNSSEC, which is recommended for CAA because the records are otherwise spoofable. The IETF is aware of these issues and the draft proposals for PQC CAA are being written with delegation reality in mind. ## DNSSEC and CAA Authenticity CAA records are only as trustworthy as the DNS infrastructure that serves them. Without DNSSEC, an attacker who can manipulate DNS responses, perhaps via a BGP hijack or a misconfigured upstream resolver, can serve forged CAA records. They can remove the CAA record entirely or change the authorized CA. A CA that does the lookup gets the bogus answer and either issues a cert it should not have or refuses to issue one it should have. DNSSEC signs DNS responses with the zone's key. A CA that requires DNSSEC for CAA validation is much harder to fool. The CA/Browser Forum baseline requires CAs to consider DNSSEC, but it does not strictly mandate that all CAA lookups be DNSSEC validated. This is a gap that operators concerned about strong assurance should close on their own end by deploying DNSSEC. In the PQC era, DNSSEC itself becomes a question. DNSSEC today uses RSA, ECDSA, and EdDSA signatures. Those signatures are vulnerable to a future quantum computer. DNSSEC has the same migration challenge as any other PKI, and the IETF DNSOP working group has draft proposals for post-quantum DNSSEC algorithms. ## CAA and Subdomain Wildcards Wildcard CAA records have always been a special case. The "issuewild" property exists exactly because a wildcard cert is more dangerous than a leaf cert. A wildcard for *.example.com lets the holder authenticate as anything-they-make-up.example.com. If a CA mis-issues a wildcard, the blast radius is enormous. In the PQC context, wildcards add another layer. The operator may want stricter algorithm requirements on wildcards than on leaf certs. They may want the wildcard to require ML-DSA while the leaf certs can be classical. The CAA grammar will need to support that distinction cleanly. ## What This Means for Operators Right Now Today, the practical advice is: First, deploy CAA if you have not already. A CAA record naming your trusted CAs is a basic hygiene step that costs nothing and prevents a real class of attack. Most major DNS providers support CAA records in their web consoles. Second, deploy DNSSEC. CAA without DNSSEC is incomplete. If your DNS provider does not support DNSSEC, switch providers. The major providers all support it. Third, when PQC CAA extensions are standardized, plan to update your records. The update is a one-line change but it should be coordinated with your CA's actual capability. Setting a CAA record requiring an algorithm your CA cannot issue will simply mean no certificates issue at all, which is its own kind of outage. Fourth, monitor CAA enforcement. The "iodef" tag lets you receive email when a CA detects a violation. This is useful both as a security alert (someone is trying to mis-issue) and as an operational alert (your CA is failing to read your CAA correctly). ## Operational Stories CAA failures have caused real outages. A few years ago a major site moved its DNS to a new provider, and the new provider quietly dropped the CAA records during the migration. The next certificate renewal worked because the CA defaulted to allowing issuance when no CAA record was present. The site continued to work, but the security posture had silently degraded. Audits later caught the missing records. In another case, an operator added a CAA record that named only the production CA, and a staging environment that used a different CA suddenly could not get certificates. The fix was to add the staging CA to the CAA record. The lesson is that CAA records affect every environment that issues for the domain, and your test environments need to be considered. In the PQC era, similar surprises will occur. An operator adds a CAA parameter requiring ML-DSA, the CA does not yet support ML-DSA in production, and renewals start failing. The mitigation is to roll out the algorithm requirement only after the CA confirms support, ideally tested first in staging. For a structured approach to migration, see [hybrid-migration-strategy-step-by-step](hybrid-migration-strategy-step-by-step.md). ## CAA, ACME, and the End-to-End Picture CAA enforcement happens at the CA, but the CA learns about CAA via DNS during ACME validation. When an ACME client asks Let's Encrypt for a certificate, Let's Encrypt does a DNS lookup for the CAA record on the requested domain. If the record exists and Let's Encrypt is not authorized, Let's Encrypt returns an error and the cert is not issued. This is a chain of trust that the operator can verify by reading the ACME error response. For more on ACME and PQC, see [acme-pqc-letsencrypt](acme-pqc-letsencrypt.md). ## CAA Record Management at Scale For organizations with many domains, CAA management becomes operational work. A typical large enterprise has dozens to hundreds of domains spanning marketing sites, internal services, customer applications, and acquisitions that came in with their own DNS configurations. Keeping CAA records consistent across all of them requires tooling. Common approaches include: Treating DNS as code. The zone files for all domains are stored in a version control repository, with CAA records as part of the standard zone configuration. Pull requests propose changes, reviewers approve, and a CI pipeline pushes to the DNS provider. This works well for organizations that already manage other infrastructure as code. Using a centralized DNS management product. Cloudflare, Route 53, and similar providers offer APIs that let you script CAA changes across many domains. The tradeoff is vendor lock-in: a script targeted at Route 53 does not directly run against another provider. Using Terraform or similar infrastructure-as-code tools. Terraform has providers for most major DNS services, and CAA records are first-class resources. This decouples the source of truth (Terraform) from the underlying provider. For PQC-specific CAA evolution, the operational pattern will likely be: update the parameter on the apex CAA record, propagate through the management tooling, monitor renewal logs to confirm the new policy is being respected. The first round of changes is the hardest because it forces the organization to actually understand which CAs are issuing for which domains. ## Common Misconfigurations A few CAA mistakes appear repeatedly in audits: Listing the wrong CA name. CAA uses an opaque string identifier for each CA, and operators sometimes use the marketing brand instead of the technical identifier. For example, "Let's Encrypt" is a brand; "letsencrypt.org" is the CAA identifier. Mistakes here cause issuance to fail. Forgetting wildcard records. An operator who needs both *.example.com and example.com to issue may set only the "issue" property, missing "issuewild". Wildcard issuance then fails. Missing iodef contact. The "iodef" tag is optional, but providing it gives you visibility into attempted policy violations. Many operators skip it and miss valuable signal. Inconsistent records across DNS providers. If a domain uses multiple DNS providers (primary and secondary), CAA records must match across them. A common mistake is updating the primary and forgetting the secondary, leading to intermittent issuance failures. Conflicting parent and child records. A CAA record on the apex and a different one on a subdomain can produce surprising results during issuance. Most CAs evaluate the closest record, but the exact behavior depends on implementation. For the post-quantum era, these misconfigurations carry the additional risk of accidentally blocking legitimate PQC certificate issuance. An organization that adds an algorithm parameter without testing it against their CA's actual capability can find their renewals failing on the first cycle after the change. ## Frequently Asked Questions **Do I need CAA records to use Let's Encrypt?** No. CAA is optional. Without it, any compliant CA can issue for your domain. **Will adding a CAA record break my existing certificates?** No. CAA only affects new issuance. Existing certs continue to validate normally. **Can I have multiple CAA records?** Yes. You can list multiple CAs as authorized by adding multiple records. CAs read all of them and consider any of them sufficient. **What happens if my DNS provider does not support CAA?** Your domain has no CAA enforcement. CAs default to allowing issuance, which is the historical behavior before CAA existed. Switch providers if you need CAA. **Is DNSSEC required for CAA?** The CA/Browser Forum baseline does not strictly require DNSSEC for CAA, but DNSSEC is strongly recommended. Without DNSSEC, CAA records can be forged via DNS attacks. ## Sources - [RFC 8659: DNS Certification Authority Authorization](https://datatracker.ietf.org/doc/html/rfc8659) - [RFC 8555: Automatic Certificate Management Environment](https://datatracker.ietf.org/doc/html/rfc8555) - [NIST Post-Quantum Cryptography Project](https://csrc.nist.gov/projects/post-quantum-cryptography) - [IETF DNSOP Working Group](https://datatracker.ietf.org/wg/dnsop/about/) - [NIST FIPS 204: ML-DSA Standard](https://csrc.nist.gov/pubs/fips/204/final) - [CAA RFC Errata and Updates](https://datatracker.ietf.org/doc/html/rfc8659) ## Related Articles - [ACME and PQC: Let's Encrypt Roadmap](acme-pqc-letsencrypt.md) - [Hybrid Encryption Explained](hybrid-encryption.md) - [Crypto Agility Explained](crypto-agility-explained.md) - [Hybrid Migration Strategy Step by Step](hybrid-migration-strategy-step-by-step.md) - [Why RSA-2048 Will Break](why-rsa-2048-will-break.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)