Certification Authority Authorization records, or CAA records, is a new DNS entry type that informs certificate authorities (CAs) 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 2013 , but not until early 2017 did CAs agreed to check these records before issuing a certificates. By September 2017 , 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.)

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.)

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.

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 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 ( * ).

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 2017-04-03 . 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 April 2017 . 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

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 ( 2018-03-01 ): 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.