CAA Records
free/v1/dns/caaRetrieves 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
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 Verification
Document CAA configuration as part of SOC 2 or ISO 27001 evidence collection.
Demonstrate certificate issuance controls for compliance audits.
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
| Name | Type | Required | Description |
|---|---|---|---|
domain | string | Required | The domain to check CAA records forExample: example.com |
Response Fields
| Field | Type | Description |
|---|---|---|
domain | string | The queried domain |
found | boolean | Whether CAA records were found (at this domain or parent) |
effective_domain | string | The domain where CAA records were found (may differ from queried domain due to RFC 8659 tree-climbing) |
is_inherited | boolean | Whether CAA policy is inherited from a parent domain |
records | array | CAA records with flags, tag, value, issuer_domain, accounturi, validationmethods, and critical flag (RFC 8659 §4 + RFC 8657) |
allowed_issuers | array | List of authorized certificate authorities |
has_iodef | boolean | Whether iodef incident reporting is configured |
iodef_targets | array | Incident reporting targets (email or URL) |
allows_wildcard | boolean | Whether wildcard certificate issuance is permitted. False when issuewild ";" denies all wildcards (RFC 8659 §4.2) |
unknown_issuer_identifiers | array | CAA `issue` identifiers that don't match any well-known CA — typically a typo, which silently disables CAA enforcement |
ct_compliance | object | Certificate 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_protected | boolean | True 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. |
recommendations | array | Actionable findings: typo'd issuer identifiers, unauthorized CT issuance, missing DNSSEC, missing iodef |
servfail | boolean | True 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 "https://api.edgedns.dev/v1/dns/caa" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d "domain=example.com"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);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.