Skip to main content

CAA Records

free
GET/v1/dns/caa

Retrieves CAA (Certificate Authority Authorization) records that specify which certificate authorities are permitted to issue certificates for a domain. Supports RFC 8659 tags including issue, issuewild, and iodef, plus RFC 8657 extensions for accounturi and validationmethods.

What It Does

Queries CAA records and parses the `issue`, `issuewild`, and `iodef` tags per RFC 8659, plus the RFC 8657 extensions `accounturi` and `validationmethods` for ACME account-binding. Tree-climbs to parent domains when no CAA is published on the queried name. Identifies authorized CAs against a curated registry of well-known identifiers (Let's Encrypt, DigiCert, Sectigo, Amazon ACM, Google Trust Services, etc.) and surfaces `unknown_issuer_identifiers` for typos — a typo silently allows ANY CA to issue, so this is a high-value safety check. Cross-references the CAA allowlist against Certificate Transparency logs (RFC 6962) via crt.sh: if a domain's CAA restricts issuance to LetsEncrypt but CT logs show a recent DigiCert cert, that's exactly the threat CAA was designed to detect. Verifies whether the zone is DNSSEC-signed (`dnssec_protected`) — without DNSSEC, an on-path attacker can spoof "no CAA" and CAs will treat the zone as permissive.

Why It's Useful

CAA only works if you keep it in sync with reality. Three failure modes cause real-world misissuance: (1) typo in the issuer identifier silently disables enforcement, (2) zone is unsigned so attackers can spoof "no CAA", (3) the policy is correct on paper but a different CA quietly issued anyway. EdgeDNS detects all three in one call. The CT cross-reference is the most security-impactful piece — most monitoring tools either check CAA or watch CT, not both.

Use Cases

Security Engineer

Certificate Security Audit

Verify that CAA records restrict certificate issuance to your organization's approved CAs only.

Prevent unauthorized certificate issuance that could enable impersonation attacks.

Compliance Officer

Compliance Verification

Document CAA configuration as part of SOC 2 or ISO 27001 evidence collection.

Demonstrate certificate issuance controls for compliance audits.

Security Engineer

Certificate Transparency Cross-Reference

Cross-reference CAA policy with Certificate Transparency logs to detect certificates issued by unauthorized CAs that violate your domain's authorization policy.

Detect policy violations and potential man-in-the-middle attacks from unauthorized certificate issuance.

Parameters

NameTypeRequiredDescription
domainstringRequiredThe domain to check CAA records forExample: example.com

Response Fields

FieldTypeDescription
domainstringThe queried domain
foundbooleanWhether CAA records were found (at this domain or parent)
effective_domainstringThe domain where CAA records were found (may differ from queried domain due to RFC 8659 tree-climbing)
is_inheritedbooleanWhether CAA policy is inherited from a parent domain
recordsarrayCAA records with flags, tag, value, issuer_domain, accounturi, validationmethods, and critical flag (RFC 8659 §4 + RFC 8657)
allowed_issuersarrayList of authorized certificate authorities
has_iodefbooleanWhether iodef incident reporting is configured
iodef_targetsarrayIncident reporting targets (email or URL)
allows_wildcardbooleanWhether wildcard certificate issuance is permitted. False when issuewild ";" denies all wildcards (RFC 8659 §4.2)
unknown_issuer_identifiersarrayCAA `issue` identifiers that don't match any well-known CA — typically a typo, which silently disables CAA enforcement
ct_complianceobjectCertificate Transparency cross-reference (RFC 6962): { checked, matches_caa, sample_issuers[], unauthorized_issuers[] }. unauthorized_issuers is the set of CT-observed CAs that are NOT in the CAA allowlist — definitive evidence of a policy violation.
dnssec_protectedbooleanTrue when the zone is DNSSEC-signed. CAA without DNSSEC is spoof-able by on-path attackers, so CAs treat unsigned "no CAA" as permissive — this flag tells you whether your CAA policy actually has teeth.
recommendationsarrayActionable findings: typo'd issuer identifiers, unauthorized CT issuance, missing DNSSEC, missing iodef
servfailbooleanTrue when DNS SERVFAIL was encountered. Per RFC 8659 §4.3, CAs MUST NOT issue certificates in this case (optional, only present on SERVFAIL)

Code Examples

cURL
curl "https://api.edgedns.dev/v1/dns/caa" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d "domain=example.com"
JavaScript
const response = await fetch(
  'https://api.edgedns.dev/v1/dns/caa?domain=example.com',
  {
    headers: {
      'Authorization': 'Bearer YOUR_API_KEY'
    }
  }
);

const data = await response.json();
console.log(data);
Python
import requests

response = requests.get(
    'https://api.edgedns.dev/v1/dns/caa',
    headers={'Authorization': 'Bearer YOUR_API_KEY'},
    params={
    'domain': 'example.com'
    }
)

data = response.json()
print(data)

Read the full CAA Records guide

Why it matters, real-world use cases, parameters, response fields, and how to call it from Claude, ChatGPT, or Gemini via MCP.

Read the guide →

Related Endpoints

External References

Learn more about the standards and protocols behind this endpoint.

Try This Endpoint

Test the CAA Records endpoint live in the playground.