[This is a guest diary submitted by J. Edward Durrett, GCUX]

While going over an SSL report from SSL Labs [1], I noticed something that I had not seen before: a check for CAA records. Certification Authority Authorization (CAA) is a DNS record which restricts which Certificate Authority can issue a certificate for a given domain [2]. Let's say I get all my Certificates for example.org from Certificate_authority.com. I can specify in my DNS that only Certificates issued by Certificate_authority.com are valid for my domain. This is done with a CAA record, which looks like this in my domain’s zone le:

example.org. CAA 0 issue "certificate_authority.com"

CAA support is going to become a mandatory standard in Certificate issuance in September 2017 [2]. That means, in the process of Certificate issuance, it will be mandatory that the the Certificate Authority check for the existence of CAA records for the domains they are issuing Certificates to [3] [4]. Consequently, if you don’t have a properly formatted CAA record for your domain, you might not get a Certificate.

Although it remains to be seen how Certificate Authorities implement this standard, failure to have a CAA record for a domain, or having an improperly formatted CAA record, may cause automated Certificate management to fail unexpectedly. This, of course would leave sites with expired/missing Certificates.

For sites running their own DNS, adding a CAA record to the zone is all that is needed. Current versions of BIND, for example, support CAA records so this can be done now. Procedures and scripts for setting up new domains need to be updated to reflect the additional step of adding CAA record before attempting to obtain a Certificate. In addition, in the event of changing Certificate Authorities, the CAA record would also need to be updated to reflect the new issuer.

For organizations that rely on third party DNS providers, the case is different. From a quick search of support pages, I only found a couple that support CAA records [5] [7]. That will probably change as September gets closer, but having a backup plan is never a bad idea.

The best reference document for I found CAA is RFC 6844 DNS Certi cation Authority Authorization (CAA) Resource Record [3]. The example I have above will work for most sites. The structure of a CAA is like this:

<FQDN> CAA <flags> <property> <value>

There are some things to note. It is possible for a domain to have more than one CAA record:

example.org. CAA 0 issue "letsencrypt.org"
example.org. CAA 0 issue "comodo.com"

This would allow a Certificate to be issued from letsencrypt.org or comodo.com. This is useful in cases where the Certificate for the smtp server is issued by letsencrypt.org and the web server uses one from comodo.com.

There are three properties which can be specified issue, issuewild, or iodef [3]. issue means a Certificate Authority is allowed to issue a Certificate for the domain. To completely bar Certificates being issued for a domain, this configuration is possible:

example.org. CAA 0 issue ";"

To only allow wild card Certificates, ones that would match *.example.org, to be issued, the issuewild property is used:

example.org. CAA 0 issuewild "certificate_authority.com"

For reporting, the iodef property can be specified. This tells the Certificate authority to send a report to either an email or an http/https service [3]:

example.org. CAA 0 issue "certificate_authority.com"
example.org. CAA 0 iodef "mailto:security@example.org"
example.org. CAA 0 iodef "https://iodef.example.org/"

In the above example, Certificate_authority.com can issue a Certificate for example.org and then Certificate_authority.com is directed to send an IODEF incident report to security@example.org and to the web service at https://iodef.example.org.

In all of the configuration examples above the flag is set as 0. Setting the flag to 128 instructs the Certificate Authority that the property is critical [3]. That is, the Certificate Authority must understand the property before issuing a Certificate.

Each Certificate Authority has some latitude to determine additional information, such as the type of Certificate or an account number, that can be specified in CAA records [3]. So it is important to check the documentation with the relevant issuer and to keep abreast of changes during implementation. And, as with everything, always test these configurations before putting them into production.

The go-to tool on Linux for checking DNS records is dig. However, dig does not yet support CAA records with the -t flag, so to check a domain type257 needs to be specified [5]:

$dig google.com type257

;; QUESTION SECTION:
;google.com.

IN TYPE257

;; ANSWER SECTION:
google.com.
0005697373756573796D616E7465632E636F6D
google.com.             86399   IN
00056973737565706B692E676F6F67

$drill google.com CAA

;; QUESTION SECTION:
;; google.com. IN CAA

;; ANSWER SECTION: google.com. 86400 IN CAA google.com. 86400 IN CAA

0 issue "pki.goog"
0 issue "symantec.com"

86399

IN

TYPE257 \# 19
TYPE257 \# 15

By piping the encoded output through xxd, we can see the property and issuer the record specifies:

$echo "00056973737565706B692E676F6F67" | xxd -r -p
issuepki.goog

The drill utility, found on FreeBSD, does support querying CAA records:

There is also a program written in Go called dnscaa which can be found on GitHub [6].

I searched through several domains looking for CAA records. This was not an exhaustive or scientific search, just a handful of domains. Outside of Certificate Authorities like Comodo and Symantec, Google was the only domain I found with CAA records. Considering that Let’s Encrypt alone has issued Certificates for close to 35 Million domains [8], there is likely a significant portion of administrators who have not published CAA records. As issuers reach out to their customers, I would expect to see more records published in the coming months.

The addition of CAA records to DNS and the critical role they will play in Certificate issuance makes an already key part of infrastructure even more valuable. Both the suppression and spofing of records being sent to the Certificate Authorities could result in an attacker obtaining an unauthorized Certificate or causing a denial of service condition [3]. Communicating with Certificate Authorities certainly would justify a method of signing and validating DNS records. Luckily, there already is such a method – DNSSEC.

Interestingly, this may ( finally!) encourage the wide spread adoption of DNSSEC. Although RFC 6844, says in section 4.1 the use of DNSSEC “is strongly RECOMMENDED but not required”, it goes on to say in section 6.4 “Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets.” [3]. If deploying DNSSEC is something that you have been putting o for the last 20 years, this might be a good time to revisit.

In conclusion, the CAA record type is relatively new to DNS yet with up to date infrastructure in place it is fairly easy to implement. The lack of CAA support by third party DNS providers might prove challenging for some organizations. As issuers roll out their policies for CAA validation, the impact of RFC 6844 will become clearer. There is plenty of time between now and September to test and adopt procedures for dealing with CAA and its role in Certificate issuance.

J. Edward Durrett, GCUX

[1] https://www.ssllabs.com/ssltest/index.html
[2] https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum [3] https://tools.ietf.org/html/rfc6844
[4] https://cabforum.org/pipermail/public/2017-March/009988.html
[5] https://support.dnsimple.com/articles/caa-record/
[6] https://github.com/weppos/dnscaa
[7] https://cloud.google.com/dns/overview#supported_dns_record_types
[8] https://letsencrypt.org/stats/