CAA Record Lookup

Anyone can ask a public certificate authority for a certificate, and the CA checks that the requester controls the domain. CAA adds a second control: the domain owner can publish which CAs are allowed to issue at all, so a mistake or a compromised validation at some other CA cannot produce a valid certificate. The page shows the policy that applies to a name, including the inherited ones.

How a CA reads CAA

RFC 8659 defines the lookup. The CA checks the exact name in the request for CAA records. If there are none, it moves to the parent, then the next parent, up to the top, and uses the first set it finds. If no name has any, issuance is unrestricted. That is why www.example.com can be governed by a single record at example.com. When a set is found, the CA may issue only if its own identifier appears in an issue record (or an issuewild record for wildcard names).

Tags and flags

A CAA record has three parts: a flag, a tag and a value. The tag issue names a CA that may issue ordinary certificates, for example letsencrypt.org or pki.goog. The tag issuewild does the same for wildcard certificates; without it, wildcards follow the issue rule. iodef gives an email address or URL where CAs report requests they refused. The flag, if set to 128, marks the record critical: a CA that does not understand the tag must refuse. A value of just a semicolon means “no CA”.

Reading the page

Enter a name and the page lists every name it checked, from the full name up, with the result at each (“none” or “1 CAA record”). Then it prints a table of the records found with their flags, tags, values and TTL, and a plain sentence under “Effective rule”, such as which CA alone may issue and how wildcards are treated. This makes it easy to see when a policy comes from a parent rather than the name you entered, and when a record at a subdomain overrides the parent’s.

A worked example

Press Sample, which looks up www.google.com. The page reports that the name has no CAA record of its own, so the policy of the closest parent, google.com, applies. At google.com it finds one record, flags 0, tag issue, value pki.goog, with a TTL of 86,400 seconds, and states the effective rule: only pki.goog may issue certificates, and wildcard certificates follow the issue rule. The list of names checked reads “www.google.com: none → google.com: 1 CAA record”.

Limits

CAA narrows who may issue; it does not stop an attacker who can already change your DNS, since they can edit the record. CAs also check DNSSEC for CAA lookups where it is available, which this page does not replicate. The page shows public DNS only and cannot tell you how a particular CA treats its identifiers. After changing a policy, remember that CAs may cache the old answer for up to the TTL. Related certificate checks are outside this tool; for the zone’s other records use the DNS Lookup.

Related tools

• DNSSEC Analyzer checks whether the zone’s answers are signed.
• DNS Lookup shows CAA beside the other record types.
• TXT Record Lookup reads the domain verification strings certificate authorities ask for.
• NS Lookup shows who controls the zone where the policy is published.