CAA Record Generator

A browser accepts a certificate when any one of the authorities it trusts has signed it. The owner of the domain takes no part in that decision. For most of the web’s history, nobody asked the owner at all.

The engineers who wrote RFC 6698 in August 2012 put the weakness in one sentence: the public model allows any of these authorities to issue a certificate for any domain name. A single authority that betrays its trust, or guards its systems carelessly, can undermine every site. They wrote with recent break-ins in mind, which had ended in governments trying to intercept traffic to sites used by millions. Certificate Transparency, described in RFC 6962 the following June, attacks the same problem from the far end. Its public logs let a domain owner see a mis-issued certificate afterwards, and its authors say frankly that logs do not prevent one.

CAA is the small preventive piece. Certification Authority Authorization arrived as RFC 6844 in January 2013, and IANA had already set aside DNS record type number 257 for it in April 2011. The current text is RFC 8659, published in November 2019.

What the record does, and what it cannot

The idea fits in a sentence. A domain owner publishes, in the owner’s own DNS zone, the names of the authorities that may issue certificates for that domain, and an authority looks for that list before it signs anything. If a list exists and the authority is not on it, the authority must refuse. The check happens once, at the issuer, before the certificate exists. Browsers do not repeat it, because RFC 8659 forbids relying parties from using CAA when they validate a certificate. The reason is practical. The records describe who may issue today, and a certificate signed last spring may have been entirely proper under last spring’s records.

So CAA binds authorities, not browsers. Its strength is the strength of a promise, and the RFC says as much: the mechanism depends on issuers observing it.

The promise was then written into the rules that public authorities are audited against. The CA/Browser Forum first took up CAA records in its Baseline Requirements with a ballot adopted in October 2014. A second ballot, titled Make CAA Checking Mandatory, took effect on 8 September 2017. Today’s text requires an authority to retrieve and process CAA for every DNS name in a certificate, and to publish the issuer domain names it answers to. A check does not last for ever either: the certificate must be issued within the record’s TTL or 8 hours, whichever is greater.

The limits deserve the same plain statement. CAA cannot stop an authority that skips the check, and it cannot prevent a mistake by an authority you did list. Anyone able to forge or suppress DNS answers on the path to the authority can make the list disappear, which is why the RFC strongly recommends DNSSEC without requiring it. The record lowers the odds of a bad certificate. Watching the logs is still how you find one.

Three tags and one flag

Each record carries a flags number, a tag and a value. In a zone file one looks like example.org. IN CAA 0 issue "ca1.example.net". The issue tag names an issuer domain, and several issue records add up to a longer list. A value that is only a semicolon names nobody, so no authority may issue. A value that does not fit the grammar is treated the same way, which means a typing error fails closed: on its own it locks out everyone, including the authority you meant. The issuer domain is an identifier each authority chooses and documents. It has to be copied from that documentation, never guessed from a company name.

The issuewild tag speaks only about wildcard certificates. When a set contains at least one issuewild record, the issue records are ignored for a wildcard request, and issuewild is ignored for every other request. One consequence surprises people. A set holding issuewild alone leaves the plain names open to any authority, a point the RFC makes with its own example.

The third tag, iodef, gives an address for reports, as a mailto or web URL. It is named after the Incident Object Description Exchange Format. The Baseline Requirements say authorities should send reports of refused requests there. On its own it restricts nothing.

The flags number has one defined bit, the critical flag, and it is written 128. Writing 1 is a common slip, and it sets a reserved bit that means nothing. Critical says that an authority which does not understand the tag must not issue at all, a safety catch for tags invented later. An unknown tag without the flag is skipped. On the wire the record is tiny: one octet of flags, one giving the tag length, the tag, then the value. The issue record shown earlier comes to 22 octets, beginning 00 05.

Climbing the tree

An authority starts at the exact name in the request. If a CAA set exists there, that set is the whole answer. If not, it removes the leftmost label and asks again, and keeps going up to, but not including, the root. The first set found wins. Sets are never merged with the ones above them. For a wildcard such as *.example.org the search begins at example.org.

A worked example shows the rule and the wildcard override together. Suppose example.org holds three records: issue “ca1.example.net”, issuewild ”;” and an iodef address. A request from ca1.example.net for api.eu.example.org finds nothing at api.eu.example.org, nothing at eu.example.org, and three records at example.org. The issue record names the authority, so it may issue. Now the same authority asks for *.example.org. The search starts at example.org and finds the same set, but an issuewild record is present, so the issue record is ignored. The issuewild value names nobody, and the request is refused. The tool above opens on exactly these records and shows both answers step by step.

Because the nearest set wins, a subdomain can loosen the policy as easily as tighten it. RFC 8657 states the corollary: CAA cannot control names whose DNS has been handed to someone else.

The climbing rule has a history, and the trouble was aliases. The 2013 text said that when a name was a CNAME, the entire search should be repeated on the alias target, parents included. A site that pointed www at a hosting company could therefore inherit a policy that company had set on a parent domain. Erratum 5065, reported in July 2017, narrowed the rule so that only the target itself was consulted. A Forum ballot titled CAA Discovery CNAME Errata followed in September 2017, weeks after checking became mandatory. RFC 8659 finished the job. The search now climbs only the requested name, and aliases are left to the resolver.

One old DNS rule still bites. A name that is an alias may hold no other records, so a CAA record placed beside a CNAME is never seen.

Binding an account and a method

Naming an authority admits every customer of that authority who can pass its validation. RFC 8657 adds two parameters to narrow that. The accounturi parameter limits a record to one account at the authority, identified by a URI, which for authorities using the ACME protocol is the account URL. The validationmethods parameter lists the ways of proving control that may be used, such as dns-01 or http-01, with an authority’s private methods carrying labels that begin ca-. Together they can say that only this account, proving control only through the DNS, may obtain a certificate.

The catch is in the RFC itself. Parameters belong to the named authority, and a domain must not assume they are honoured unless the authority says so. That is changing. A Forum ballot adopted in May 2026 says authorities should process both parameters, and must from 15 March 2027. Account URIs also become public the moment they enter the DNS.

Email certificates are a separate matter. RFC 9495 added an issuemail tag in October 2023, and states that issue and issuewild do not restrict them.

Rolling out without locking yourself out

The realistic failure is refusing your own renewal. Before publishing anything, list every authority that issues for any name under the domain, including those used on your behalf by a hosting, delivery or mail provider. The transparency logs are a good place to look. Publish issue records for all of them, then decide about wildcards. Check for subdomains with their own sets, since those replace yours. Keep the TTL modest while you are still adjusting, because an authority may rely on a check for the TTL or eight hours.

Two details of the file format cause most broken records. In a zone file a semicolon starts a comment, so a value containing one must sit inside quotes, or everything after it silently vanishes. And a DNS server too old to know the type can still carry the record in the generic form of RFC 3597, written as type 257 with the same octets in hexadecimal.

A web page can show what a set of records means. It cannot show what is actually published, because the tool above makes no DNS query at all. It cannot know which issuer domain your authority answers to, or whether that authority honours a parameter.

The record is a guest list, and the doormen have agreed to read it. Write it carefully, keep it current, and check the logs to see who got in.