CAA Record Validator

Introduction:

Certificate Authority Authorization records are a way for a domain owner to state which certificate authorities are allowed to issue certificates for that domain. They help reduce surprise certificates and give you a clear policy signal before you request or renew a certificate for a new service.

You provide a domain name and the tool looks up the published authorization records, then it summarizes what it found and highlights patterns that can cause issuance to fail. It also points out missing best practices so you can tighten rules with confidence and document what you intended clearly.

A realistic use is an operations review before a migration where you want to ensure only your chosen certificate authority can issue for the new hostnames. If a record uses a critical flag with an unfamiliar tag, the tool warns that some issuers may refuse to proceed.

Treat the result as a policy check, not proof that a certificate exists or that an account is active, and avoid testing private internal domains if you do not want a third party resolver to see them.

Technical Details:

Certificate Authority Authorization (CAA) is a Domain Name System (DNS) record type that lets a domain publish certificate issuance permissions as a set of simple rule rows. Each row has an integer flags field, a tag that names the rule, and a value that carries an issuer domain, a reporting address, or parameters.

This validator measures what is published for the hostname you enter, then computes a normalized view so logically identical rows compare cleanly. It also evaluates a small set of safety checks and reports them as PASS, WARN, or FAIL to help you spot misconfigurations quickly.

The checks focus on outcomes that matter operationally, such as whether you have any issuer restrictions, whether wildcard issuance is explicitly controlled, and whether a critical flag is paired with an unknown tag. Values for issue and issuewild are normalized by lowercasing and sorting semicolon parameters, and iodef is checked for basic Uniform Resource Identifier (URI) syntax for mailto and https schemes.

Results are best read as a policy health signal rather than a guarantee of issuance. Different resolvers can return different answer sets during propagation, so recheck after changes and compare using the same resolver when you want like for like results.

Processing pipeline

1. Extract the hostname from a domain name, URL, or email style input.
2. Convert the hostname to ASCII using Internationalized Domain Names in Applications (IDNA) handling from the URL parser.
3. Query CAA via DNS over HTTPS (DoH) using the selected resolver or Auto.
4. Abort the DoH request after the configured timeout in milliseconds.
5. Parse each answer as flags, tag, and value, and mark malformed rows.
6. Normalize issue and issuewild values by sorting and lowercasing parameters.
7. Validate iodef values as mailto or https and record a note on failure.
8. Compute checks for unknown critical tags, issuer constraints, and duplicates.

Core rule checks

A row is treated as critical when bit 128 is set in the flags field. Unknown critical tags are highlighted because they can block issuance in some implementations.

Symbols and units

Worked example

0 issue "letsencrypt.org; ParamB=2; ParamA=1"
0 issuewild ";"
0 iodef "mailto:security@example.com"
128 unknown "value"

Interpretation of statuses

When values sit close to a decision boundary, treat WARN as a prompt to confirm intent rather than an error. Always resolve FAIL first because it can stop issuance entirely.

Parameters you can control

Constants and preset values

Units, precision, and normalization

• Heads‑up Lookup time is rounded with nearest millisecond rounding and reported as an integer.
• TTL is taken from the first answer returned by the resolver and is shown in seconds when present.
• Flags are parsed as base 10 digits, and the critical bit is tested with flags & 128.
• Tags are lowercased for comparisons, and unknown tags are still shown as received.
• For issue and issuewild, the issuer domain is lowercased and a trailing dot is removed.
• Semicolon parameters are trimmed, lowercased, sorted lexicographically, and rejoined with ; .
• Duplicate detection compares flags, tag, and normalized value case insensitively.

Validation rules and bounds

Inputs and outputs

Networking and storage behavior

Lookups are performed with fetch requests to the selected DoH endpoint, using an accept header of application/dns-json and a query that sets name, type=CAA, and ct=application/dns-json. The page keeps results in memory while you view them and resets state on each new validation run.

Performance and determinism

For n answer rows, parsing, normalization, and duplicate detection run in O(n) time with O(n) memory for the dedupe set. Given the same resolver response, the normalized record list and check outcomes are deterministic, but the resolver response itself can differ across providers and time.

Assumptions and limitations

• Heads‑up The Auto mode only falls back to the second resolver when the first request fails to fetch.
• TTL is shown only when the resolver provides it and only from the first answer entry.
• The validator recognizes only issue, issuewild, and iodef as known tags.
• Unknown non critical tags are still listed, and only unknown critical tags trigger a failure.
• iodef validation is intentionally lightweight and does not fully validate mail addresses.
• Parameter normalization can change the display order compared to the original DNS text.
• Duplicate detection is based on normalized values, so cosmetic differences are treated as duplicates.
• The deny all conflict check is implemented only for issue, not for issuewild.
• Builder output uses flags 0 and does not attempt to set the critical flag.
• The builder uses a fixed TTL of 3600 seconds in its snippet template.

Edge cases and error sources

• Leading dots, trailing dots, and a final root dot are removed before querying.
• Internationalized domains are converted to ASCII form by the URL parser when possible.
• Email style inputs use the text after the last @ as the hostname.
• URLs without a valid scheme are handled with a best effort split and can misparse unusual strings.
• Resolvers can return an empty answer for a valid domain, which is reported as no records found.
• Heads‑up Network errors and blocked fetch requests can look like missing records in the final message.
• Timeout aborts are treated as fetch failures and can trigger the Auto fallback behavior.
• Quoted answer data with multiple quoted segments is concatenated, which can surprise if quotes are meaningful.
• Consecutive semicolons produce empty parameter segments that are discarded during normalization.
• Flag values that are not digits cause parsing to fail and the row is marked malformed.
• Non ASCII whitespace can survive trimming differently across environments and affect displayed values.
• Very large answer sets are uncommon, but copying and exporting large tables can be slow.

Security considerations

• CAA checks do not confirm certificate ownership, only published issuance policy.
• Unknown critical tags can block issuance, but issuer handling can vary by implementation.
• Do not paste secrets into the domain field, since it is intended for hostnames only.
• If you work with internal hostnames, prefer a resolver and network path you trust.
• Use deny all directives carefully, and avoid mixing deny and allow values accidentally.
• After changing records, recheck from multiple networks if you suspect stale caches.

Scientific and standards references

Authoritative references include the IETF specification for Certificate Authority Authorization, the IETF specification for DNS over HTTPS, and the IANA registry of DNS record types.

Privacy and compliance

Lookup requests are sent from your browser directly to the selected resolver endpoint, and the page does not persist results to local or session storage.

Step-by-Step Guide:

Certificate Authority Authorization records tell you which issuers are permitted, and this guide walks you from a domain input to a clear PASS WARN FAIL summary you can act on.

1. Enter the Domain as an apex hostname, or paste a URL or email address to extract it.
2. Optionally choose a Resolver to compare results, or leave it on Auto.
3. Adjust Timeout if your network is slow, and set it to 0 to disable extra abort timing.
4. Select Builder preset to draft recommended issuer rows for your chosen certificate authority.
5. Run validation, then read the Checks tab and fix FAIL items first.
6. Use the Builder output as a starting point, and add deny all rows only if that matches your policy intent.

Pro tip: when debugging, run the same domain through two resolvers back to back and compare normalized values rather than raw text.

You should finish with a normalized record list and a small checklist you can use to update DNS confidently.

Troubleshooting:

• Domain is required. Enter any hostname, or paste a URL or email so the hostname can be extracted.
• No CAA records found. The domain may not publish CAA, or the resolver returned no answers for this type.
• Timeouts. Increase the timeout, or set it to 0 to remove the extra abort timer.
• Unexpected FAIL for unknown critical tag. Remove the critical flag or use a tag the issuer recognizes.
• Duplicate logical entries. Remove redundant rows after normalization, especially when only spacing differs.
• Deny all conflict. Do not combine issue ";" with permissive issue rows in the same set.

Advanced Tips:

• Tip Prefer explicit issue and issuewild rules to document intent for future changes.
• Tip Use a single resolver while iterating, then cross check with a second resolver before rollout.
• Tip Normalize values in your own zone file reviews so duplicates do not sneak in with formatting changes.
• Tip If you need to deny issuance, add deny all rows only after confirming all required issuers are listed.
• Tip Keep an incident mailbox ready for iodef, and review it periodically for routing changes.
• Tip Capture the JSON summary when filing a ticket so others can reproduce the same check context.

Glossary:

CAA

Certificate Authority Authorization, a DNS rule set for certificate issuance.

Flags

Integer field where bit 128 marks a tag as critical.

Tag

Rule name such as issue, issuewild, or iodef.

issue

Lists which certificate authorities may issue non wildcard certificates.

issuewild

Lists which certificate authorities may issue wildcard certificates.

iodef

Reporting URI, accepted as mailto or https in this validator.

Normalization

Lowercasing and sorting parameters to compare logical equality.

TTL

Time to Live value returned by the resolver, in seconds.

FAQ: