What is a DNS CAA record?

A DNS CAA (Certification Authority Authorization) record is a specialized type of DNS entry that allows domain owners to explicitly declare which Certificate Authorities (CAs) are permitted to issue SSL/TLS certificates for their hostnames. Since September 2017, all public Certificate Authorities are legally mandated by the CA/Browser Forum to verify these records before issuing any digital certificate. If a CA detects a CAA record that does not list their identifier, they are strictly prohibited from signing the certificate, safeguarding your domain against unauthorized or malicious issuance.

What happens if a domain has no CAA records published?

If a domain does not publish any CAA records, standard industry rules dictate that any public Certificate Authority in the world is legally authorized to issue SSL certificates for that domain and all its subdomains. This default permissive behavior leaves your brand vulnerable to domain hijacking if an attacker manages to compromise a less secure CA or intercept DNS traffic during a domain validation check. Publishing even a single CAA record immediately locks down the entire zone to only your designated, trustworthy CA partners, substantially improving your domain security posture.

What is the difference between issue, issuewild, and iodef tags?

The "issue" tag is used to authorize a specific Certificate Authority to issue standard SSL/TLS certificates, which applies to both standard single-domain and wildcard requests unless overridden. The "issuewild" tag specifically targets wildcard certificates (e.g., *.yourdomain.com), enabling you to define a separate policy for wildcards or block them completely by using a semicolon value. Finally, the "iodef" tag defines an incident reporting mechanism, specifying a secure URL or email address where CAs must report any fraudulent or invalid certificate requests that violate your published policy.

What do the 0 and 128 Flags represent?

Flags represent the critical status of the CAA record and determine how Certificate Authorities must handle tags they do not recognize. Flag "0" is standard and indicates a non-critical policy, meaning that if a CA does not support custom tags inside your record, they can safely ignore them and proceed with validation. Conversely, Flag "128" marks the record as critical; if a CA encounters a critical record containing tags or parameters it does not understand, it is legally required to immediately abort the certificate issuance process and report the violation if an iodef tag is specified.

How does a CAA record interact with subdomains and wildcard domains?

CAA records follow a hierarchical lookup path down the domain tree. If a resolver queries a subdomain like sub.blog.example.com and finds no CAA record, it will automatically climb up the tree, checking blog.example.com and then the root example.com until it finds a policy. This recursive search makes it easy to set a single catch-all policy at the apex domain level. If you wish to have a different policy for a specific subdomain, you can publish a dedicated CAA record directly on that host, which will override the parent zone's settings entirely.

Can I authorize multiple Certificate Authorities for my domain?

Yes, you can authorize as many Certificate Authorities as your infrastructure requires by publishing multiple separate CAA records. Each CA must be declared on its own dedicated record line in your DNS zone file. For example, you can publish one line permitting Let's Encrypt for your daily automated development setups, and another line permitting DigiCert for your enterprise EV certificates. Resolvers will evaluate the full list of published records, and as long as a CA matches at least one valid entry, it can successfully issue your certificates.

What is the recommended CAA configuration to prevent all wildcard certificate issuance?

To block wildcard certificates completely while still allowing standard single-domain certificates, you should publish a standard authorization record and an explicit block record. You would define a standard record using the "issue" tag pointing to your preferred CA (such as letsencrypt.org), and a separate record using the "issuewild" tag set to a semicolon value (e.g. yourdomain.com. IN CAA 0 issuewild ";"). The semicolon is a standard reserve token that represents an empty CA set, which legally prevents any Certificate Authority from issuing wildcard certificates for your domain.

DNS CAA Record Generator

Configure Certificate Authority Authorization (CAA) records for your DNS registry. Secure your domain by selecting allowed CAs, setting wildcards, and reporting violations client-side.

1. Domain Information

Domain Name

2. Authorized Certificate Authorities

Check the CAs authorized to issue certificates for your domain name.

Let's Encrypt letsencrypt.org

DigiCert digicert.com

Sectigo (Comodo) sectigo.com

Amazon Web Services amazonaws.com

GlobalSign globalsign.com

GoDaddy godaddy.com

3. SSL Policy Tags & Options

Wildcard Permission

Critical Policy Flag

Incident Reporting Email (adds iodef:)

CAs will send emails detailing unauthorized SSL issuance attempts.

Compiled DNS CAA Record Valid CAA

DNS Registrar Setup

Enter these parameters inside your DNS manager dashboard (e.g. Cloudflare, Route 53, Namecheap, GoDaddy):

Field

Value

Record Type

CAA

Host / Name

@ (or blank)

TTL

3600 (or 1 hour)

Field Breakdown for Registrar Inputs:

Flag

Tag

issue / issuewild

Value

"letsencrypt.org"

Deep-Dive: How DNS CAA Records Protect Domain Certificates Under the Hood

In the modern web security ecosystem, trust is highly distributed. Any legitimate Certificate Authority in the world is permitted to issue a globally valid SSL certificate for your domain as long as they perform a basic automated DNS challenge validation. If an attacker gains compromised access to a single low-security CA or manages to hijack your routing temporarily via BGP or DNS spoofing, they can generate valid SSL certificates for your hostnames and conduct highly stealthy Man-in-the-Middle (MITM) attacks. CAA records defend against this vulnerability by limiting certificate issuance explicitly to only CAs that follow your strict policy guidelines.

Under the hood, a Certification Authority Authorization (CAA) record uses a standardized syntax consisting of flags, tags, and values. When a Certificate Authority receives a certificate signing request (CSR) for a domain, they are legally required to query your DNS registry to fetch any active CAA records. The CA evaluates each record sequentially. If no CAA records exist, the CA proceeds with issuance. If CAA records are found, the CA must match its own identifier (e.g. letsencrypt.org) against the authorized values in the issue or issuewild fields. If there is no match, the CA must refuse to issue the certificate and must report the unauthorized attempt to the endpoint listed in your iodef reporting tag.

By designing and scaffolding these records in a clean client-side generator, administrators can prevent configuration mistakes that might block legitimate automated renewals. For example, if your production environment relies on Let's Encrypt for automatic HTTPS provisioning, failing to explicitly authorize letsencrypt.org in your CAA zone file will cause your automated renewal scripts to fail, resulting in expired SSL warnings that instantly block visitors from accessing your digital products.

Comparative Use-Case Matrix

SSL Certification Scenario	Developer Local Sandbox	Production CI/CD Strategy
Apex Domain Protection	Scaffold standard records authorizing key CAs for development test domains.	Publish apex CAA records to automatically protect all subdomains through standard inheritance.
Wildcard Restriction	Visualize and restrict wildcard certificate tags visually before generating zone files.	Enforce a strict `issuewild ";"` directive to prevent malicious actors from issuing generic wildcards.
Violation Auditing	Configure secure test mailto addresses to receive mock CA violation reports.	Route real-time CAA report payloads to security logging webhooks for automated threat detection.

Before vs. After Code Comparison

Adding a CAA record to your BIND zone file is straightforward but syntax errors will invalidate the record. The comparative examples below illustrate a standard permissive configuration versus a secured CAA directive:

❌ UNSECURED (No CAA Records Published)

# No CAA directives are published in the DNS zone file
# Result: Any CA globally can issue certificates for the domain
# Vulnerability: Highly susceptible to BGP hijacking attacks!

✓ SECURED CAA BIND ZONE DIRECTIVE

# Authorize Let's Encrypt for standard certs
example.com.  IN  CAA  0  issue  "letsencrypt.org"
# Block all CAs from issuing wildcard certificates
example.com.  IN  CAA  0  issuewild  ";"
# Route policy violations to security mailto
example.com.  IN  CAA  0  iodef  "mailto:[email protected]"

Common Mistakes & Troubleshooting Guidelines

Accidental Wildcard Lockouts: A common mistake is configuring an issuewild ";" rule while expecting Let's Encrypt wildcard certificates to renew automatically. If you use wildcard certificates, you must explicitly declare your CA under the issuewild tag instead of blocking it.
Missing Parent Zone Checks: CAs recursively look up parents if subdomains lack CAA records. If your main domain example.com blocks a CA, all subdomains like shop.example.com inherit that block unless a local CAA record overrides it.
Unmatched Provider Identifiers: Make sure you input the exact identifier for your CA. For instance, entering amazon.com instead of amazonaws.com will block the AWS Certificate Manager from validating your domain.

Best Practices for SSL Issuance Governance

For the best security posture, combine a robust CAA policy with active certificate transparency (CT) log monitoring. Standardize on one or two Certificate Authorities and explicitly restrict all others using a comprehensive CAA configuration. Set up the iodef tag pointing to a dedicated security mailbox to receive instant programmatic notifications of unauthorized certificate requests. Regularly audit your zone configurations and run verification checks to ensure your CAA rules remain aligned with your operational requirements.