CAA Record Checker/Generator
CAA is DNS certificate policy, so DNSSEC context helps judge whether the answer is authenticated.
DNS SecurityAny trusted CA can issue for your domain until you say otherwise. CAA is how you say otherwise — cheap to publish, surprisingly sharp in effect, and mostly dangerous to the people who forget they published it.
Publicly trusted CAs are required to check CAA before issuing — not periodically, not at renewal reminders, but at the moment of issuance. A record like example.com. CAA 0 issue "letsencrypt.org" turns the universe of possible issuers into a list you wrote. Mis-issuance by a CA you never authorized becomes a detectable policy violation with an audit trail instead of a quiet possibility, and the well-meaning colleague ordering a certificate from a retired vendor gets a clean refusal instead of a certificate.
Equally important is what CAA does not do. It is evaluated at issuance only: publishing or changing records has zero effect on certificates that already exist, which also means CAA is not an emergency revocation lever. And it constrains issuance, not usage — a certificate issued before your policy, or under a subdomain's divergent policy, keeps working until it expires. Pair CAA with Certificate Transparency monitoring if you want to see what actually got issued; the two controls cover each other's blind sides.
The lookup semantics produce most real-world surprises. A CA checks the exact name being certified, and if no CAA set exists there, climbs parent by parent until it finds one — then uses that set alone. A single CAA record on dev.example.com therefore silently replaces your carefully designed apex policy for everything under dev. Audits should look at subdomains, not just the apex, and the CAA Record Checker/Generator reads live answers — including the generic RFC 3597 wire-format some resolvers return — and validates the tag syntax you actually published.
Three tags carry the policy. issue authorizes a CA for host certificates; issuewild governs wildcards separately, falling back to issue when absent; iodef names a reporting address for violation attempts. The empty-issuer form issue ";" means nobody may issue — occasionally exactly right for parked domains, more often a leftover that surfaces as a mysterious refusal months later.
Naming a CA still leaves a wide door: anyone who can pass that CA's domain validation can obtain a certificate — which is exactly the move an attacker with temporary DNS or web control performs. RFC 8657 narrows the door. accounturi binds issuance to one specific ACME account, so domain validation alone no longer suffices without your account key. validationmethods restricts which challenge types are acceptable, letting you rule out methods your infrastructure never uses.
For automated ACME estates this is the strongest cheap upgrade available, with one operational caveat: the account URI must track reality. Re-registering an ACME account and forgetting the CAA pin produces self-inflicted refusals that look exactly like a CA outage. Document the pin next to the account credentials, and make updating one imply checking the other.
The most common CAA incident is entirely self-made: the team switches certificate vendors, nobody updates the record, and nothing happens — for a while. Existing certificates run on. The first renewal through the new CA fails weeks later, surfaces as an expiry alert, and gets triaged as a CA problem while the actual cause sits in your own zone.
Prevention is procedural: adding or changing a CA becomes a documented step that includes the CAA record, and certificate automation gets a pre-renewal check that the intended CA is currently authorized. Decode what you actually deployed with the SSL Certificate Decoder when the issuer chain is in question, and keep the record list short and honest — every authorized CA is attack surface for validation-based issuance, so authorize what you use and nothing else.