DNS CAA Record: Controlling Certificate Issuance

A CAA (Certificate Authority Authorization) record specifies which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. Without CAA records, any CA in the world can issue a certificate for your domain if they follow their standard validation process. With CAA records, you restrict issuance to only the CAs you explicitly authorize.

CAA records are a security control. They do not prevent all forms of certificate misissuance, but they add a layer of defense that is free, easy to set up, and checked by every major CA before issuing a certificate. This guide explains how CAA records work, how to configure them, and what to watch out for. For the broader topic of certificate security, see the Certificate Transparency guide.

How CAA Records Work

Since September 2017, all publicly trusted certificate authorities are required to check CAA records before issuing a certificate (per the CA/Browser Forum Baseline Requirements). The process works like this:

1. You request a certificate from a CA (Let's Encrypt, DigiCert, Sectigo, etc.).
2. Before issuing the certificate, the CA queries your domain's DNS for CAA records.
3. If no CAA records exist, the CA proceeds with issuance (no restriction).
4. If CAA records exist and the CA is listed, the CA proceeds with issuance.
5. If CAA records exist and the CA is not listed, the CA refuses to issue the certificate.

This check happens automatically. You do not need to do anything at the time of certificate issuance beyond having the correct CAA records in place.

CAA Record Syntax

CAA records have a specific format:

example.com.    86400    IN    CAA    0 issue "letsencrypt.org"

The fields are:

Flag: A number (usually 0). If set to 128, the flag indicates that the property is "critical" and CAs that do not understand it must refuse to issue.

Tag: The property type. Three tags are defined:

• issue -- Authorizes the CA to issue standard certificates.
• issuewild -- Authorizes the CA to issue wildcard certificates specifically.
• iodef -- Specifies a URL or email address for violation reports.

Value: The CA's identifying domain name (for issue and issuewild) or a reporting URI (for iodef).

Setting Up CAA Records

Allowing a Single CA

To allow only Let's Encrypt to issue certificates for your domain:

example.com.    CAA    0 issue "letsencrypt.org"

Allowing Multiple CAs

To allow both Let's Encrypt and DigiCert:

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

Controlling Wildcard Certificates

To allow Let's Encrypt for regular certificates but only DigiCert for wildcard certificates:

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

If you have issuewild records, only the CAs listed in issuewild records can issue wildcards. CAs listed only in issue records cannot issue wildcards.

If you do not have any issuewild records, the issue records apply to both regular and wildcard certificates.

Blocking All Certificate Issuance

To prevent any CA from issuing certificates for a domain:

example.com.    CAA    0 issue ";"

The empty value (just a semicolon) means "no CA is authorized." This is useful for domains that should never have certificates issued, such as internal domains or parked domains.

Setting Up Violation Reporting

The iodef tag tells CAs where to report violation attempts (when someone tries to get a certificate but the CAA check fails):

example.com.    CAA    0 iodef "mailto:[email protected]"
example.com.    CAA    0 iodef "https://example.com/caa-report"

Not all CAs send violation reports, but setting up the iodef record gives you a chance of being notified about unauthorized issuance attempts.

Common CA Identifier Values

Each CA has a specific identifier to use in CAA records. Here are the most common:

| CA | CAA Value | |---|---| | Let's Encrypt | letsencrypt.org | | DigiCert | digicert.com | | Sectigo (Comodo) | sectigo.com | | GoDaddy | godaddy.com | | GlobalSign | globalsign.com | | Amazon (ACM) | amazon.com | | Google Trust Services | pki.goog | | Cloudflare (via DigiCert/Let's Encrypt) | digicert.com and letsencrypt.org | | ZeroSSL | sectigo.com |

If you are unsure which CA your current certificate comes from, check the certificate details in your browser or use an SSL checker.

CAA Record Inheritance

CAA records follow a specific inheritance model. When a CA checks for CAA records, it starts at the exact hostname being issued (e.g., www.example.com) and walks up the domain hierarchy until it finds a CAA record set:

1. Check www.example.com for CAA records.
2. If none found, check example.com for CAA records.
3. If none found, check com for CAA records (usually none).
4. If no CAA records found anywhere, any CA can issue.

This means you can set CAA records at the domain level and they apply to all subdomains that do not have their own CAA records. If you need different policies for different subdomains, add CAA records at the subdomain level:

; Default policy for all subdomains
example.com.         CAA    0 issue "letsencrypt.org"

; Different policy for the API subdomain
api.example.com.     CAA    0 issue "digicert.com"

In this configuration, www.example.com can only get certificates from Let's Encrypt (inherits from example.com), while api.example.com can only get certificates from DigiCert (has its own CAA records).

Checking CAA Records

Using dig

dig CAA example.com

# Short output
dig CAA example.com +short

Using nslookup

nslookup -type=CAA example.com

Online Tools

Many SSL checking tools display CAA records as part of their analysis. This is useful for verifying that your CAA records are correctly configured before requesting a certificate.

What CAA Records Do Not Protect Against

CAA records are a useful security layer but not a complete defense:

Compromised CAs. If a CA is compromised or acts maliciously, they can ignore CAA records. CAA is an honor system enforced by CAs themselves, not by DNS infrastructure.

Domain validation vulnerabilities. If an attacker can compromise your DNS (changing CAA records along with everything else) or intercept HTTP/email validation, they can get a certificate regardless of CAA records.

Previously issued certificates. CAA records only affect future certificate issuance. They do not revoke or invalidate certificates that were already issued before the CAA records were added.

CAs you forgot to list. If you use a CDN, SaaS platform, or hosting provider that provisions certificates on your behalf, and you forget to include their CA in your CAA records, certificate renewals will fail.

CAA records work best as part of a layered security approach. Combine them with Certificate Transparency monitoring to detect any certificates issued for your domain, whether authorized or not.

CAA Records and Certificate Renewal

This is the most common operational issue with CAA records. You set up CAA records allowing only DigiCert. Everything works fine. A year later, your hosting provider switches from DigiCert to Let's Encrypt for automatic certificate renewals. The renewal fails because Let's Encrypt is not in your CAA records.

To prevent this:

1. Know all your certificate sources. Inventory every service that provisions certificates for your domain: your hosting provider, CDN, email service, and any other service that uses your domain with HTTPS.
2. Include all relevant CAs. Add CAA records for every CA used by your services.
3. Monitor certificate renewals. Set up monitoring to detect renewal failures before certificates expire. An SSL certificate monitor alerts you when a certificate is approaching expiry, giving you time to fix CAA issues.
4. Review after infrastructure changes. Whenever you change a hosting provider, CDN, or any service that provisions certificates, review your CAA records.

CAA with DNSSEC

CAA records are most effective when combined with DNSSEC. Without DNSSEC, an attacker who can tamper with DNS responses can forge or remove CAA records during the CA's check. With DNSSEC, DNS responses are cryptographically signed, preventing tampering.

If you are serious about certificate security, enable DNSSEC alongside your CAA records. See What Is DNSSEC? for setup guidance.

References

1. RFC 8659, "DNS Certification Authority Authorization (CAA) Resource Record," November 2019. https://datatracker.ietf.org/doc/html/rfc8659
2. CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates," https://cabforum.org/baseline-requirements/
3. Let's Encrypt, "CAA Records," https://letsencrypt.org/docs/caa/