Generador y comprobador de registros CAA online
Un registro CAA indica las autoridades de certificación que pueden emitir certificados para tu dominio; toda CA de confianza pública debe consultarlo antes de emitir. Crea aquí los registros, comprueba un conjunto de registros pegado antes de publicarlo o consulta qué devuelve ahora mismo el DNS para un dominio.
La generación de registros y la comprobación de registros pegados se hacen en tu navegador. «Comprobar DNS» envía el nombre de dominio —y sus nombres padre, a medida que la consulta CAA sube por la jerarquía— al resolvedor DNS-over-HTTPS que elijas (Cloudflare o Google). No se envía nada más, y nuestros servidores no reciben nada.
El nombre en el que se publican los registros; también abarcan todos los nombres por debajo de él que no tengan registros CAA propios.
Si se deja vacío, las líneas usan el TTL predeterminado de la zona.
Direcciones mailto: o https:, una por línea.
S/MIME, certificados de marca y contactos
Separa varias direcciones con espacios.
Un número por línea, con el código de país.
Corrige esto primero
- ErrorEscribe un nombre de dominio.
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.