How to Audit Your Entire Organization's DNS for Missing CAA Protections

Auditing your entire organization's DNS for missing Certification Authority Authorization (CAA) records is a critical step in preventing unauthorized SSL/TLS certificate issuance. Without CAA records, any publicly trusted certificate authority can issue a valid certificate for your domains, exposing your infrastructure to malicious issuance and compromise. By implementing a systematic audit, you gain complete visibility and control over which security vendors are authorized to generate cryptographic assets for your web properties.

To streamline this process across multiple domains, you can use the CAA Lookup tool on XiaTools to quickly inspect existing DNS configurations and identify exposed zones.

Understanding CAA Records and DNS Security

A Certification Authority Authorization (CAA) record is a type of DNS resource record that allows domain owners to declare which certificate authorities (CAs) are authorized to issue certificates for that domain. Introduced as an industry standard to mitigate the risk of mis-issuance, CAA records work by instructing CAs to check the domain's DNS zone before processing an incoming certificate signing request (CSR).

If a CA receives a request for example.com but finds that your CAA records only permit a specific vendor, that CA must reject the issuance request. This mechanism acts as an organizational guardrail against rogue internal teams spinning up certificates with external providers or accidental misconfigurations at your DNS hosting provider.

How CAA Records Work

When a CA performs validation prior to issuing a certificate, it queries the target domain for CAA records. The lookup follows a specific ascent algorithm:

1. Queries the exact target domain (e.g., sub.example.com).
2. If none exist, it climbs up the tree to the parent domain (e.g., example.com).
3. It continues climbing until it finds a valid CAA record set or reaches the root zone.

This behavior means you can define a baseline CAA record at the root domain level (like example.com) that automatically protects all subdomains, unless a specific subdomain overrides it.

Step-by-Step Guide to Auditing Organizational CAA Records

Executing a comprehensive CAA audit across an enterprise requires a structured approach. You must inventory all domains, query their current DNS states, compare findings against your security policy, and remediate gaps.

Step 1: Inventory All Corporate Domains and Subdomains

Before you can audit records, you need a complete list of your digital assets. Pull domain inventories from your asset management databases, registrar accounts, and cloud service providers. Include primary domains, marketing microsites, country-code top-level domains (ccTLDs), and legacy systems.

Step 2: Query Existing CAA Configurations

You can query DNS records using command-line utilities or automated scripting. For a quick individual check, use standard tools like dig or PowerShell.

Open your terminal and run a query for the CAA record type on your domain using dig:

dig example.com CAA +noall +answer

If configured correctly, you will see output similar to this:

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

If you are on Windows, open PowerShell and query the record using Resolve-DnsName or nslookup:

Resolve-DnsName -Name example.com -Type CAA -ErrorAction SilentlyContinue

Step 3: Analyze the Output and Identify Gaps

Review your query results against three distinct criteria:

• Absence of Records: If the query returns no records, your domain is completely unprotected. Any public CA can issue certificates for it.
• Overly Permissive Records: If you see generic wildcards or unauthorized CAs, your attack surface remains open.
• Missing Incident Reporting: If the iodef property is absent, you will not receive automated forensic alerts when an unauthorized CA denies an issuance request.

Exact Syntax and Record Types

Writing correct CAA syntax is vital. A malformed record can either break certificate issuance entirely or fail to protect your domain. CAA records consist of flags, tags, and values.

Tag Name	Description	Example Syntax	Purpose
issue	Authorizes a CA to issue single or wildcard certificates.	0 issue "sectigo.com"	Restricts standard certificate generation.
issuewild	Authorizes a CA to issue wildcard certificates exclusively.	0 issuewild "digicert.com"	Restricts wildcard generation (overrides issue).
iodef	Specifies a URL or email for violation reports.	0 iodef "mailto:sec@example.com"	Receives reports on blocked issuance attempts.

Understanding Critical Flags

The integer at the beginning of the record is the flag. Currently, only flag 0 (non-critical) and flag 128 (critical) are defined:

• Flag 0: Indicates that CAs can ignore unknown properties if they do not understand them, ensuring backward compatibility.
• Flag 128: Indicates that the property is critical. If a CA does not understand the property tag, it must abort certificate issuance.

In most enterprise environments, you should use flag 0 unless you have a strict compliance requirement to block non-compliant CAs entirely.

Remediation: Adding and Fixing CAA Records

Once your audit exposes missing or incorrect protections, you must update your DNS provider zones. Because provider interfaces differ, locate your DNS management console and navigate to the DNS Zone Editor or Manage Records section.

Adding a CAA Record via DNS Providers

1. Log into your DNS hosting provider console.
2. Navigate to the Domain Management or DNS Zone settings page.
3. Click Add Record and select CAA from the record type dropdown menu.
4. Enter the target host (leave blank or use @ for the apex domain).
5. Set the flags value to 0.
6. Select the tag as issue or issuewild.
7. Enter the authorized CA domain name string (e.g., letsencrypt.org).
8. Save and publish the changes.

Example Zone File Entries

If you manage your DNS via BIND zone files (such as on a BIND server utilizing IP ranges like 192.0.2.0/24 or IPv6 networks like 2001:db8::/32), your zone file format will look like this:

$TTL 86400
@   IN  SOA ns1.example.com. admin.example.com. (
        2023100101 ; Serial
        3600       ; Refresh
        1800       ; Retry
        604800     ; Expire
        86400 )    ; Minimum TTL

@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

; CAA Records
@   IN  CAA 0 issue "letsencrypt.org"
@   IN  CAA 0 issue "digicert.com"
@   IN  CAA 0 iodef "mailto:dns-security@example.com"

Common Mistakes and How to Fix Them

Even experienced engineers encounter pitfalls when deploying CAA records. Review these common misconfigurations to keep your audit clean.

Forgetting Subdomain Inheritance Rules

A common mistake is adding CAA records only to specific subdomains while leaving the root domain blank, or vice versa. Remember that CAs check upwards. If you secure example.com with Let's Encrypt, but api.example.com has no records, the root record applies. However, if api.example.com has any CAA record defined, it completely overrides the root domain settings. Always test subdomain resolution explicitly.

Using Incorrect CA Domain Names

CAs specify exact domain identifiers that must be used in CAA records. For example, using letsencrypt instead of letsencrypt.org will cause validation to fail because the string does not match the CA's authorized identifier. Always consult your CA's official documentation for their exact CAA domain string.

Neglecting Wildcard Separation

Many administrators assume an issue tag covers wildcard certificates. However, according to RFC 6844, the issuewild tag takes precedence for wildcard requests. If you omit issuewild, a CA might issue a wildcard certificate even if issue restricts them, depending on their interpretation. Always explicitly define both tags if you use wildcards.

CAA Audit Checklist

Use this quick checklist to ensure your organizational audit is thorough and complete:

• Inventory all organization-owned domains, subdomains, and vanity URLs.
• Run automated or manual CAA queries against every inventoried asset.
• Verify that primary domains have explicit issue and issuewild records.
• Confirm that unauthorized CAs are excluded from your record sets.
• Implement iodef monitoring addresses to capture failed issuance alerts.
• Test DNS propagation and zone file syntax after making updates.
• Schedule recurring monthly or quarterly automated DNS audits.