CAA Governance Snapshot
{{ domainASCII || domain }}
{{ effectiveScopeLabel }} Source: {{ effectiveDomain }} Score {{ policyScore }}/100 {{ checkCounts.pass }} pass {{ checkCounts.warn }} warn {{ checkCounts.fail }} fail Alias: {{ aliasTarget }} TTL {{ ttl }} s {{ cert_scope === 'wildcard' ? 'Wildcard' : 'Leaf' }} scope Resolver: {{ resolverUsed }} {{ timeMs }} ms
Domain
labels
ms
# Flags Tag Value Normalized Notes
{{ idx + 1 }} {{ row.flags }} {{ row.tag }} {{ row.value }} {{ row.normalized }} {{ row.note || '-' }}
{{ rec.level }}
  • {{ rec.text }}
# Check Status Notes
{{ idx + 1 }} {{ c.label }} {{ c.status }} {{ c.note || '-' }}
Stage Host Status Answers Note
{{ row.stage }} {{ row.host }} {{ row.status }} {{ row.answerCount }} {{ row.note }}
# Flags Tag Value Notes
{{ idx + 1 }} {{ row.flags }} {{ row.tag }} {{ row.value }} {{ row.note || '-' }}
Zone snippet
{{ builderSnippet }}

  
:

Introduction

Certificate Authority Authorization, usually shortened to CAA, is the DNS policy layer that lets a domain owner name which certificate authorities may issue certificates for a host. That matters because certificate issuance is a security control before it is an administrative chore, and a weak or ambiguous CAA policy can leave room for mis-issuance or renewal surprises during migrations, failovers, and vendor changes.

This validator checks the published CAA policy for the hostname you enter and shows the effective result after alias handling and parent-domain lookup. It is built for the practical moment when you want to confirm what a public CA is likely to see before requesting a certificate, tightening wildcard rules, or comparing a live record with the policy your team thought it had published.

The package does more than return a raw RRset. Its summary badges show the ASCII hostname, effective policy source, package score, pass or warn or fail counts, alias target, TTL, certificate scope, resolver, and elapsed lookup time. The result tabs then split the same run into the effective RRset, the compliance matrix, the resolution trail, a policy composer, a chart, and a JSON snapshot so you can review the policy from different angles without rerunning the lookup.

That breadth is useful because CAA can be easy to misread. A hostname may inherit policy from a parent label, wildcard issuance can behave differently from leaf issuance, and an alias chain can hide where the relevant RRset was actually found. The tool is strongest when the question is “what policy is in DNS and how would this package assess it?” rather than “will my CA definitely issue?”

That boundary matters. RFC 8659 treats CAA as an authorization control that a CA checks before issuance, not as proof that a certificate already exists or that every operational precondition has been satisfied. This package also sends live DNS-over-HTTPS queries from the browser to public resolvers, so it is sensible to avoid pasting private internal names if you do not want those names exposed to an external resolver.

Everyday Use & Decision Guide

The input accepts more than a bare domain. You can paste an apex domain, a host name, a URL, or even an email address, and the page normalizes that input down to a hostname before querying DNS. That is useful in day-to-day work because certificate tickets, monitoring alerts, and chat messages often contain pasted URLs rather than neat hostnames.

The next decision is scope. For ordinary host certificates, the default leaf scope is the right starting point. If you are checking a wildcard request, switch the certificate scope to Wildcard before running the validation, because the compliance matrix then evaluates issuewild precedence and fallback behavior instead of treating wildcard logic as a side note.

Start in Effective RRset after the lookup completes. That table shows the rows the package actually evaluated, including flags, tag, visible value, normalized value, and notes such as malformed rows, deny-all directives, repeated parameters, or unknown tags. It is the fastest way to answer “what exactly did the tool parse?” before you think about the score.

Compliance Matrix is the policy review view. It checks whether a relevant CAA policy was found, whether the rows parse cleanly, whether a base issuer allowlist exists, whether wildcard behavior is explicit, whether iodef looks usable, whether duplicate logical rows or deny-all conflicts exist, whether the selected builder preset is already covered, and whether stricter RFC 8657 parameters appear satisfiable. The recommendation banner surfaces up to three fail items and three warning items so the highest-friction fixes are visible immediately.

Resolution Trail becomes important when the result is surprising. It records each CNAME stage and each CAA lookup stage with the host checked, response status, answer count, and a short note. If a host inherits from a parent label or resolves through an alias target first, this is the tab that explains why the summary box names a different effective domain than the one you typed.

Policy Composer turns the same page into a drafting aid. You can choose a preset for Let's Encrypt, DigiCert, Google Trust Services, or a mixed preset, optionally add issuewild, optionally add deny-all rows, and add an iodef URI. The tool then builds tabular rows, a zone-style snippet with a fixed 3600 TTL, and exportable CSV or DOCX output. If you need a machine-readable bundle instead, the JSON tab exposes the parsed records, checks, trail, score, recommendations, and builder state together.

Technical Details

RFC 8659 defines the Relevant RRset as the CAA records discovered by walking up the DNS hierarchy from the requested name until a CAA RRset is found. The package mirrors that idea with a configurable parent walk capped at 10 labels and defaulting to 6. When Follow CNAME chain is enabled, it also performs up to four explicit CNAME lookups first so you can see alias behavior in the result rather than leaving that step completely hidden inside a resolver.

Each returned answer is parsed into a flags field, a property tag, and a value. Known tags are issue, issuewild, and iodef. For issue and issuewild, the package lowercases the issuer name, splits semicolon parameters, sorts parameter tokens alphabetically, and builds a normalized string so logically identical rows compare cleanly even if their original order differed. Duplicate detection is based on that normalized representation, not just the raw text shown by the resolver.

The package score is intentionally opinionated. It starts at 100, subtracts 22 points for every FAIL row, subtracts 10 points for every WARN row, and leaves PASS and INFO unchanged. That makes the score easy to interpret as a hardening signal, but it is not an RFC metric, a CA audit score, or a substitute for reading the individual checks.

score = 100-22×fail_count-10×warn_count
Package checks for CAA Record Validator
Check How this package evaluates it
Relevant policy located Passes when at least one CAA RRset is found after alias handling and parent walk. If none is found, the tool warns that public CAs may issue without CAA restriction.
Records parse cleanly Fails when any row cannot be split into numeric flags, a tag, and the remaining value text.
No unknown critical tags Fails when bit 128 is set and the tag is not one of the package's recognized tags. RFC 8659 says a CA must not issue when a relevant RRset contains an unknown critical property.
Base issuer allowlist Warns when no issue rows are present, because no non-wildcard CA allowlist is being enforced.
Wildcard scope policy Passes for wildcard requests when issuewild exists, warns when wildcard issuance falls back to issue, and fails when neither tag constrains wildcard issuance.
iodef syntax Warns when no iodef row exists and fails when the value is not a mailto: or https: URI that the package accepts.
Duplicate logical entries Warns when normalized rows collide after case folding and parameter sorting.
Deny-all conflict Fails when an issue ";" deny-all row appears alongside non-empty issue allowlist rows.
RFC 8657 parameter checks Reviews accounturi and validationmethods on issue and issuewild rows. Strict mode turns unsatisfiable values into fail items instead of warnings.
Builder preset coverage and AD signal Compares live issue issuers with the selected composer preset and records whether any response surfaced the DNSSEC Authenticated Data flag.

Two standards details deserve extra care. First, RFC 8659 says issuewild applies only to wildcard names and takes precedence over issue when present. That is why a host can look acceptable in leaf mode yet still warn in wildcard mode. Second, RFC 8659 allows iodef reporting by mailto:, http:, or https:, but this package deliberately validates only mailto: and https:, so an http: reporting URL will be marked invalid here even though the RFC permits it.

RFC 8657 adds accounturi and validationmethods as restrictive controls for issuance. The RFC warns that misconfiguration can cause legitimate requests to be refused, and the package surfaces that risk directly. It treats repeated accounturi or validationmethods parameters as unsatisfiable, requires a single accounturi value to parse as https:, and accepts only the three method tokens hardcoded in the tool: http-01, dns-01, and tls-alpn-01. That is stricter than the RFC examples, which also show CA-specific method tokens such as xyz-01 and ca-foo.

From a privacy and trust perspective, the page is simple but not invisible. The browser issues live DNS-over-HTTPS requests to Cloudflare or Google, and the JSON export reproduces the queried host, timing, trail, parsed rows, checks, and builder data already visible on screen. The AD bit is shown as a resolver security signal, but it is only a hint from the resolver response, not a complete proof that the entire issuance path is protected by DNSSEC-aware validation.

Step-by-Step Guide

  1. Enter the target name in the Domain field. If you paste a URL or an email address, the package extracts the hostname before querying DNS.
  2. Open Advanced when the default assumptions are not enough. Choose Wildcard in Certificate scope for wildcard issuance checks, switch resolvers if you want to compare Cloudflare with Google, and disable Follow CNAME chain only when you intentionally want to ignore alias behavior.
  3. Adjust Tree-walk depth if the expected policy may live several labels up the hierarchy. Increase it when a subdomain is likely to inherit from a higher parent label.
  4. Click Validate CAA and read the summary badges first. They tell you where the effective policy came from, how many checks passed or warned or failed, how long the lookup took, and which resolver answered.
  5. Open Effective RRset to confirm the visible rows and notes. If a row looks suspicious, compare Value and Normalized before editing DNS so you know whether the problem is a syntax issue, a duplicate logical row, or a deny-all conflict.
  6. Use Compliance Matrix and Policy Pulse Map for the high-level judgment. If RFC 8657 warnings are the only problem and you want a stricter review, turn on RFC 8657 strict mode and rerun the check.
  7. When the result is “No CAA records found” or the effective domain looks unfamiliar, open Resolution Trail. If the trail shows an alias target or a higher parent label than expected, correct the DNS location or use Policy Composer to draft the rows you actually meant to publish.

Interpreting Results

A high package score usually means the hostname has an explicit issuer allowlist, no unknown critical tags, no obvious logical conflicts, and few or no warning conditions. That is good operational hygiene, but it still does not prove that your CA account is authorized, that domain validation will succeed, or that every CA will make identical decisions in the middle of a DNS propagation window.

A middle score often means the policy exists but leaves some room for interpretation. Common examples are no issuewild row for wildcard requests, no iodef reporting URI, duplicate rows that are harmless but confusing, or a preset mismatch because the selected composer preset includes issuers you have not actually authorized. Those are usually hardening tasks rather than emergency failures.

A low score deserves closer attention because the package has found one or more conditions that could block issuance or undermine policy clarity. Unknown critical tags, deny-all conflicts, or unsatisfiable RFC 8657 parameters are the clearest examples. When those appear, the individual check notes matter more than the chart.

The effective scope label is also part of the interpretation. Direct policy means the tool found CAA where you looked. Alias target policy means the package followed a CNAME chain before it found CAA. Inherited parent policy means the controlling RRset lives higher in the DNS hierarchy. Those are materially different operational states even if the final score is identical.

Worked Examples

A clean leaf-policy review

Suppose app.example.com resolves to a direct RRset containing 0 issue "letsencrypt.org", 0 issue "digicert.com", and 0 iodef "mailto:security@example.com". In leaf mode the package sees an explicit non-wildcard allowlist, a reporting URI, and no obvious logical conflicts. The compliance matrix stays mostly green, the score remains high, and the JSON export gives you a compact evidence bundle for the change record.

A wildcard request that inherits too much

Now switch to wildcard scope for a hostname whose RRset contains only issue rows. RFC 8659 says issuewild takes precedence when present, but if it is absent the tool falls back to the regular issue rows and marks that as a warning rather than a pass. That is the package telling you the wildcard policy is workable but not explicit.

Troubleshooting a surprising no-record result

Imagine you expect policy at service.example.com but the page reports No CAA records found. Open Resolution Trail. If the trail shows a CNAME hop to another host or stops before the parent label that actually carries the policy, the corrective path is clear: enable CNAME following, raise the tree-walk depth, or publish the RRset at the label you intended. If the trail shows repeated empty answers all the way up, the absence is real rather than a display bug.

FAQ

Does this prove that a certificate can be issued right now?

No. It validates the published CAA policy and scores it according to package rules. It does not prove account authorization, domain-control validation success, rate-limit status, or CA-specific exception handling.

Why does wildcard mode warn when leaf mode looks fine?

Because wildcard issuance has its own logic. If issuewild is absent, the package falls back to issue rows for wildcard requests and records that as less explicit than a dedicated wildcard policy.

Why did my iodef URL fail here?

The validator accepts only mailto: and https: syntax. RFC 8659 also permits http:, but this package intentionally uses a tighter check and will flag plain HTTP as invalid.

Why did RFC 8657 parameters fail even though they look plausible?

The package is strict about repeated parameters and accepted tokens. A single accounturi must parse as an https: URL, and validationmethods must contain only the method names this tool recognizes. In strict mode those issues become fail items instead of warnings.

What does the AD badge really tell me?

It only tells you that at least one resolver response reported the DNSSEC Authenticated Data flag. It is a useful hint, but it is not a complete audit of DNSSEC deployment or CA validation behavior.

Glossary

Relevant RRset
The CAA record set that applies after the DNS hierarchy is searched upward from the requested label until a CAA RRset is found.
issue
The property that names certificate authorities allowed to issue non-wildcard certificates for the applicable domain.
issuewild
The property that controls wildcard issuance and overrides issue for wildcard requests when it is present.
iodef
The property used to publish an address for reports about certificate requests or issuance events that violate policy.
AD bit
The Authenticated Data flag returned by a resolver to indicate DNSSEC-authenticated data was observed in the response path.

References