CAA Record Generator and Checker — генератор и проверка записей CAA

What a CAA record does

A CAA record (RFC 8659) names the certificate authorities that may issue certificates for a domain. Every publicly trusted CA must look it up before issuing (Baseline Requirements §4.2.2.1) and refuse when it is not named. 0 issue "letsencrypt.org" allows one CA; several issue records allow several, because properties add up. issue ";" allows none. issuewild overrides issue for wildcard certificates only, so issuewild ";" forbids wildcards while leaving ordinary certificates to the issue records. iodef gives a mailto: or https: address where a CA may report a request that broke the policy. A domain without any CAA record leaves every CA free to issue — CAA is an opt-in limit, not a default.

The value a record names is the CA's CAA identifier, which is not always its brand: Let's Encrypt is letsencrypt.org, Google Trust Services pki.goog, DigiCert accepts digicert.com among others. The generator picks identifiers from the CCADB "All CAA Identifiers" report, the list CAs publish of the domains they recognise, and says when an identifier is shared by several CA owners. For a CA outside the report, type its identifier yourself.

Accounts and validation methods

RFC 8657 adds two parameters to issue and issuewild. accounturi binds issuance to one ACME account, so a stolen DNS challenge or a different customer of the same CA cannot obtain a certificate for your name. validationmethods limits how control of the domain may be proven, for example to dns-01. Ballot SC-098 makes CAs honour both from 15 March 2027 (BR §4.2.2.1.2). The generator writes one record per account, since two accounturi parameters in one property could never be satisfied, and warns about combinations that cannot work: a wildcard certificate cannot be validated over HTTP or TLS-ALPN (BR §3.2.2.4), so issuewild restricted to http-01 forbids every wildcard. Draft method labels such as dns-persist-01 are not yet in the IANA registry; the generator points to the ca-tbr-<n> label every CA must recognise from 2027.

Four ways to publish

DNS software and providers take CAA in different shapes, so the result comes in four: zone-file lines for BIND, NSD, Knot and PowerDNS; RFC 3597 generic lines (TYPE257 \# …) for software older than the CAA type; tinydns-data lines for djbdns; and the bare values (0 issue "letsencrypt.org") that web panels such as Cloudflare and Route 53 ask for. The notes under the result say how each of those expects them. Pasting records into Check records lints them before you publish: syntax, reserved and critical flags, issuer domains, parameters, report addresses — and shows which CAs the set would allow, for names and for wildcards.

What a CA sees: the DNS check

A CA does not only look at the exact name. RFC 8659 §3 makes it climb towards the root — www.shop.example.com, then shop.example.com, then example.com — and the first name that has CAA records decides. Aliases are followed: when a name is a CNAME, the target's records count, but the climb continues at the parent of the original name. A lookup that fails is not permission: the Baseline Requirements let a CA treat a failure as "no records" only after a retry and only for a domain that is provably unsigned, and a DNSSEC validation failure must stop issuance. Check DNS follows the same steps against a public DNS-over-HTTPS resolver, retries a failed query once, repeats it with checking disabled to tell a validation failure from an unreachable zone, and reports each step, the records that apply, whether the resolver validated them with DNSSEC, and a verdict for each CA in the CCADB report. For DNSSEC itself, follow the chain of trust in the DNSSEC inspector.

What leaves your browser

Generating records and checking pasted ones happen entirely in your browser. Check DNS asks the resolver you pick — Cloudflare at cloudflare-dns.com or Google at dns.google — for the CAA records of the domain and, as the climb requires, its parent names. The resolver sees those names and nothing else: the requests carry no cookies and no referrer, and our servers are not involved. A share link keeps the policy, the domain or the pasted records after the # of the address, which browsers never send to a server.

CAA limits which CAs a careless or compromised validation can use; it cannot stop a permitted CA from issuing by mistake. That is what Certificate Transparency monitoring is for — see Certificate Transparency for developers. With certificates shrinking to 47 days, validations happen far more often, which makes accounturi and validationmethods more valuable each year: 47-day TLS certificates explains the schedule.