Stop CAs from misissuing certifi­cates for your domains with CAA

Certification Authority Authorization records, or CAA records, is a new DNS entry type that informs certificate authorities (CA) about which CAs are allowed to issue a certificate for a given domain name. It’s a way for domain owners to block unaffiliated CAs from unknowingly issuing a certificate to a third-party against the expressed wishes of the domain owner.

The CAA records were formally standardized in , but not until did CAs agreed to check these records before issuing a certificates. By , all CAs must check and verify any CAA records before issuing a certificate. (This policy change applies to the 51 members of the CA/Browser Forum, with other CAs to follow).

It’s voluntary for domain owners to set these DNS records, but having them can add an extra level of protection against anyone who seek to impersonate their servers.

Here is an example section from a BIND zone file that shows what would be a common CAA resource record deployment:

example.com.  IN  CAA  0 issue "digicert.com"
example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild ";"
example.com.  IN  CAA  0 iodef "mailto:security@example.com"

These four records instructions compliant CAs in the following ways:

  • Only the two CAs, Let’s Encrypt and DigiCert — as identified by their domain names, are allowed to issue certificates for the domain.
  • No CA is allowed to issue a wildcard certificate for the domain. (";" represents an empty string — meaning no one.)
  • Any CA other than Let’s Encrypt and DigiCert are encouraged to report any attempts at having them issue a certificate for the domain to security@example.com by email.

The value 0 isn’t a priority score as seen in other DNS record types, but a options flag. The value of 0 means it’s a regular record that should be processed if supported. A value of 1 means the CA must process the record or cancel the issuance process if the record isn’t understood. Setting this value to 1 in the above example would mean that neither DigiCert nor Let’s Encrypt could issue a certificate for the domain as neither has both identities.

The syntax of a CAA record is defined in full in RFC 6844. Check with your certificate authority about the correct values, domain names, and any additional options you may be required to set before deploying CAA records.

Here are a few points to consider and some general recommendations when deploying CAA record:

  • Allow your current CA plus one fallback CA to issue certificates. It’s a good practice to have a fallback option for any eventualities or disputes with your current CA.
  • Use multiple name servers from DNS multiple providers. If one DNS server or provider is compromised, than the other may still hold the correct CAA records and would block any certificate issuance request. (This depends on the CA’s DNS lookup implementation.)
  • Set long TTL of up to a week, as these records aren’t expected to change often. Long-lived caching can be considered a security feature when it comes to CAA records.
  • Certificates can be issued to subdomains. Be sure you set CAA records for common high-value target subdomains, even if you don’t use them, like www, web, secure, mail, shop, etc. Additionally, you can set up a wildcard record (*).
  • Sign your CAA records using DNSSEC to prevent any in-transit tampering.

Current adoption

Out of Alexa Internet’s list of top one million domains, only 307 domains had deployed one or more CAA records as of . CAA is a fairly new record type, and CAs only recently committed to honoring it.

A few of Google’s domain has CAA records, including google.com, googleusercontent.com, and appspot.com. They haven’t created records for their regional domains (like google.com.au) nor youtube.com.

A handful of certificate authorities have also created CAA records for their own domains comodo.com, including entrust.net, and symantec.com. Branded variations of these CAs don’t necessarily have CAA records. There was no correlation between which CAs support CAA checks and which have CAA records on their own domain names as of .

I believe it’s fair assessment to say that one of the largest barriers to CAA record adoption is that many managed DNS service providers don’t provide many standard DNS record types, and few of the web’s most used providers support it.

Support from managed DNS providers

Recent versions of popular DNS server software, including BIND and PowerDNS, all support CAA records. When it comes to managed DNS hosting providers, things don’t look as good. Several of the most used DNS providers don’t support creating CAA records. Below is a break down of the most common managed DNS hosting providers.

The following managed DNS hosting providers support creating CAA records:

  • Amazon AWS Route 53
  • Cloudflare
  • Constellix DNS /
    DNS Made Easy DNS
  • DNSimple
  • Dyn DNS
  • Gandi
  • GoDaddy DNS
  • Google Cloud DNS
  • UltraDNS
  • Zilore DNS

The following managed DNS hosting providers does not support creating CAA records:

  • Akamai DNS
  • Network Solutions DNS

Update (): The above overview was updated to reflect that Cloudflare, Dyn, Gandi, and GoDaddy DNS now support CAA records.

These are some of the world’s most popular DNS providers and they’ve historically been very slow to adopt new DNS entry types (if at all). We can only hope that more of them will add support for the CAA record type.

As the recent certificate misissuance from Symantec show, CAs aren’t beyond misissuing certificates. If your DNS provider support creating CAA records, I’d recommend you create CAA records for your domain. The administrative overhead of adding some extra DNS records is very low, and when used together with other security tools, CAA records might help thwart a potential future malicious coup of your website.