This was news to me in a few ways; first, there's a new DNS resource record called CAA (Certificate Authority Authorization) and second, Certificate Authorities are now required to check that record before issuing a certificate, to determine if they're allowed to do so.
Cool!
What's a CAA (Certificate Authority Authorization)?
When in doubt, consult the RFC: RFC 6844, DNS Certification Authority Authorization (CAA) Resource Record.
In short, it looks like this:
ttias.be. CAA 0 issue "letsencrypt.org"
The CAA record is a new resource record, next to the usual A, CNAME, MX, TXT, … records you might already know.
The syntax is as follows;
CAA <flags> <tag> <value>
Which translates to;
- flag: An unsigned integer between 0-255.
- tag: An ASCII string that represents the identifier of the property represented by the record.
- value: The value associated with the tag.
In reality, you'll see the configurations mostly as follows;
ttias.be. CAA 0 issue "letsencrypt.org"
-> this means that only Let's Encrypt can issue a certificate for the domain “ttias.be”. Note this also covers the subdomains, like www.
ttias.be. CAA 0 issue "letsencrypt.org"
ttias.be. CAA 0 issue "globalsign.com"
-> this means both Let's Encrypt and Globalsign can issue certificates for the domain “ttias.be”.
ttias.be. CAA 0 issuewild "letsencrypt.org"
-> the issuewild tag indicates that wildcard certificates can be issued for “ttias.be”, covering “*.ttias.be”, but not “*.mail.ttias.be”.
Receiving notifications of CAA violations
If a certificate authority receives a certificate request for a domain, but the CAA record denies it, the CA can send a notification to the domain owner. This is configured & managed via the iodef tag.
ttias.be. CAA 0 iodef "mailto:m@ttias.be"
-> this configures it so that if a CA receives a certificate request for “ttias.be”, you'll be notified on “m@ttias.be”.
ttias.be. CAA 0 iodef "/callback"
-> this configures it so that a HTTPS call will be done to that URL to inform you of this certificate request attempt. It's unclear whether it's a GET or a POST or what the payload is, that might depend on the CA?
Query'ing CAA records
Alas, this doesn't work yet in dig, as you get the A record if you query for a CAA record.
$ dig google.com CAA
google.com. 143 IN A 172.217.17.142
Current versions of dig don't understand the CAA record yet, so you have to be explicit and query for Resource Record Type 257, the identifier given to CAA.
$ dig google.com type257
google.com. 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D
google.com. 86399 IN TYPE257 \# 15 00056973737565706B692E676F6F67
Notice how the value isn't exactly readable? That's because it's binary encoded and needs to be decoded first, to be human readable.
Update: the dig version on CentOS 7 works just fine.
$ dig -v
DiG 9.9.4-RedHat-9.9.4-38.el7_3.2
$ dig google.com CAA
google.com. 86400 IN CAA 0 issue "pki.goog"
google.com. 86400 IN CAA 0 issue "symantec.com"
Tools like dnscaa provide that ability.
$ ./digcaa google.com
google.com. 86399 IN CAA 0 issue "symantec.com"
Support for CAA records are coming in the next version of DNS Spy, too.
Do I have to add CAA records to get a certificate?
No, just like HSTS, the CAA records are completely optional. You should add them, for increased security though.
As of September 2017, Certificate Authorities are obligated to check for CAA records and honor those preferences. Not having CAA records is essentially the same as saying “everyone can issue a certificate for my domain”.