CAA Record Example: CAA Records vs DNSSEC for Protecting Domain Certificate Issuance

Use CAA records to control which Certificate Authorities may issue certificates for your domain, and use DNSSEC to prove that the DNS answers carrying those rules have not been tampered with. They solve different problems, and the best setup uses both. CAA checking became mandatory for public CAs in 2017 under CA/Browser Forum rules, which means a CA must check your CAA policy before issuing a public TLS certificate [source: CA/Browser Forum].

TLDR: A CAA record says, “Only these CAs may issue certificates for this domain.” DNSSEC says, “This DNS answer is authentic and has not been altered.” For example, if example.com has a CAA record allowing only Let’s Encrypt, then another CA should refuse issuance. In a company with 50 domains and 300 subdomains, CAA can cut accidental certificate issuance paths sharply, while DNSSEC reduces the risk of spoofed DNS responses during validation.

CAA Records vs DNSSEC: The Short Version

CAA, or Certification Authority Authorization, is a DNS record type. It lets a domain owner publish a list of CAs allowed to issue certificates for that domain.

DNSSEC, or Domain Name System Security Extensions, signs DNS data. It helps resolvers verify that DNS responses are real and unchanged.

They are often confused because both live in DNS and both support certificate security. But they are not substitutes.

• CAA controls certificate issuance.
• DNSSEC protects DNS integrity.
• CAA without DNSSEC is still useful.
• DNSSEC without CAA does not restrict which CA may issue certificates.

A Practical CAA Record Example

Here is a simple CAA setup for a domain that only wants Let’s Encrypt to issue standard certificates, blocks wildcard certificates, and asks for incident reports by email:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

That says three things:

1. issue "letsencrypt.org" allows Let’s Encrypt to issue certificates for example.com.
2. issuewild ";" blocks wildcard certificates, such as *.example.com.
3. iodef tells CAs where to send reports if someone requests a certificate that violates the policy.

The 0 is the flag value. Most everyday CAA records use 0. A flag value of 128 marks the tag as critical, which tells a CA that it must understand the tag before proceeding.

Honestly, it feels like DNS control panels make this harder than it needs to be. Some ask for the whole record in one box. Others split the flag, tag, and value into separate fields. Expect to waste a few minutes checking whether the quote marks are inserted by you or by the interface.

What CAA Protects Against

CAA reduces the chance of certificate misissuance. That includes cases where:

• A developer uses the wrong CA for a production domain.
• An attacker tricks a less careful CA into issuing a certificate.
• An old vendor still has validation access for a forgotten subdomain.
• A wildcard certificate is requested when company policy forbids it.

CAA is especially useful for organizations with many teams. Picture a SaaS company with 12 product squads, 80 subdomains, and three cloud providers. Without CAA, any public CA that can validate control may issue a certificate. With CAA, security can limit issuance to one or two approved CAs and get warning emails when policy is ignored.

CAA is not magic, though. It does not encrypt anything. It does not stop phishing by itself. It does not replace certificate monitoring. It simply gives CAs a rulebook they are required to check before issuing.

What DNSSEC Protects Against

DNSSEC protects the authenticity of DNS answers. It uses cryptographic signatures, including records such as RRSIG, DNSKEY, and DS. A validating resolver can check those signatures and reject forged or altered responses.

This matters because certificate validation often depends on DNS. A CA may check DNS records during domain validation. If an attacker can spoof DNS answers, the attacker may try to mislead a CA or a user. DNSSEC makes that much harder when validation is performed correctly.

The annoying part is setup. DNSSEC often requires action at both the DNS provider and the registrar. You usually publish keys in your DNS zone, then add a DS record at the registrar. One typo can cause validation failures. TTLs can make fixes feel slow. It is not hard forever, but the first setup can be unforgiving.

Where CAA and DNSSEC Overlap

CAA and DNSSEC meet when a CA asks DNS, “Is this CA allowed to issue?” The answer may be a CAA record. DNSSEC can then help prove that the CAA answer is legitimate.

That combination is stronger than either mechanism alone:

• CAA says who may issue.
• DNSSEC helps prove the CAA answer is real.
• Together, they reduce both policy abuse and DNS tampering.

Still, DNSSEC does not force a CA choice. If your domain has DNSSEC but no CAA record, then you have protected DNS answers, but you have not told CAs which ones are allowed. That is like locking the filing cabinet but leaving the approval form blank.

Common CAA Patterns

Allow one CA only:

example.com. 3600 IN CAA 0 issue "digicert.com"

Allow two CAs:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"

Block all certificate issuance:

example.com. 3600 IN CAA 0 issue ";"

Allow wildcard certificates only from a specific CA:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "digicert.com"

This last setup allows Let’s Encrypt for normal certificates and DigiCert for wildcard certificates. Use it only if that policy matches your real process. A messy CAA policy is worse than no policy because everyone assumes it means more than it does.

Subdomains and Inheritance

CAA has inheritance behavior. If a CA checks login.example.com and finds no CAA record there, it checks higher in the domain tree, such as example.com. This lets you define a broad policy at the parent domain.

You can also publish CAA at a subdomain for a stricter or different rule. For example, payments.example.com could be limited to a corporate CA, while the rest of the domain uses Let’s Encrypt.

Be careful with old subdomains. They are a favorite source of problems. A forgotten vendor hostname with weak controls can become a certificate risk, even if your main site is tidy.

Recommended Setup

For most production domains, use this order:

1. Inventory your certificates. List every CA currently used.
2. Create a CAA policy. Start with the CAs you actually use.
3. Add iodef. Send reports to a monitored security inbox.
4. Test issuance. Confirm your normal renewal flow still works.
5. Enable DNSSEC if your DNS provider supports it well.
6. Monitor certificates. Use Certificate Transparency alerts.

A solid baseline might look like this:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:cert-alerts@example.com"

This is simple, readable, and strict enough for many teams. If you need multiple CAs, add them clearly. If you need wildcard certificates, define that policy on purpose.

Final Takeaway

CAA and DNSSEC protect different layers of the same certificate trust chain. CAA tells CAs who is allowed to issue. DNSSEC helps prove DNS data has not been forged. If you care about reducing certificate mistakes, start with CAA. If you also want stronger DNS integrity, add DNSSEC and monitor it closely.