CAA Record Generator and Checker — générateur et vérificateur d’enregistrements CAA
Un enregistrement CAA désigne les autorités de certification autorisées à émettre des certificats pour votre domaine ; toute AC publique doit le vérifier avant d’émettre. Créez ici les enregistrements, vérifiez un ensemble d’enregistrements collé avant de le publier, ou regardez ce que le DNS renvoie en ce moment pour un domaine.
La génération des enregistrements et la vérification des enregistrements collés ont lieu dans votre navigateur. « Vérifier le DNS » envoie le nom de domaine – ainsi que ses noms parents, à mesure que la recherche CAA remonte – au résolveur DNS-over-HTTPS que vous choisissez (Cloudflare ou Google). Rien d’autre n’est envoyé, et nos serveurs ne reçoivent rien.
Le nom sous lequel les enregistrements sont publiés ; ils couvrent aussi tous les noms situés en dessous qui n’ont pas leurs propres enregistrements CAA.
Si le champ reste vide, les lignes utilisent le TTL par défaut de la zone.
Adresses mailto: ou https:, une par ligne.
S/MIME, certificats de marque et contacts
Séparez plusieurs adresses par des espaces.
Un numéro par ligne, avec l’indicatif du pays.
À corriger d’abord
- ErreurSaisissez un nom de domaine.
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.