CAA-Eintragsgenerator und -Checker
Ein CAA-Eintrag nennt die Zertifizierungsstellen, die Zertifikate für deine Domain ausstellen dürfen; jede öffentlich vertrauenswürdige CA muss ihn vor der Ausstellung prüfen. Erstelle die Einträge hier, prüfe eingefügte Einträge, bevor du sie veröffentlichst, oder sieh nach, was das DNS für eine Domain gerade zurückgibt.
Generierung und Prüfung eingefügter Einträge laufen in deinem Browser. „DNS prüfen“ sendet den Domainnamen – und die übergeordneten Namen, zu denen die CAA-Abfrage aufsteigt – an den DNS-over-HTTPS-Resolver deiner Wahl (Cloudflare oder Google). Sonst wird nichts gesendet, und unsere Server erhalten nichts.
Der Name, unter dem die Einträge veröffentlicht werden; sie gelten auch für jeden Namen darunter, der keine eigenen CAA-Einträge hat.
Bleibt das Feld leer, verwenden die Zeilen die Standard-TTL der Zone.
Adressen mit mailto: oder https:, eine pro Zeile.
S/MIME-Zertifikate, Mark Certificates und Kontakte
Trenne mehrere Adressen durch Leerzeichen.
Eine Nummer pro Zeile, mit Ländervorwahl.
Zuerst beheben
- FehlerGib einen Domainnamen ein.
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.