A Certification Authority Authorization (CAA) record is used to specify which certificate authorities (CAs) are allowed to issue certificates for your domains.
Background
When well behaved certificate authorities (CAs) issue new certificates they follow certain procedures. These procedures are documented in their Certification Practice Statement (CPS) which should be a public document. For example the CA needs to make sure that the entity that have ordered a new certificate is actually the owner of that domain. There is today different levels of assurance. For example the CA need to be “more” sure that you are actually the owner of a domain in order to issue a certificate that gives you “the green padlock”
There is now a way for domain owners to influence these procedures using a new DNS record type, CCA (Certification Authority Authorization)
The CAA record and CPS
RFC 6844 describes the format of the record and how CAs should handle it if they decide to take it into consideration.
Before issuing a certificate, a compliant CA MUST check for publication of a relevant CAA Resource Record set. If such a record set exists, a CA MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA Resource Record set or (2) an exception specified in the relevant Certificate Policy or Certification Practices Statement applies.
https://tools.ietf.org/html/rfc6844
In this way the domain owner can influence the security of the CA infrastructure by publishing these resource records into DNS. If a company exclusively use one certificate provider CAA records will give the CA another tool to verify that they can issue certificates for a specific domain. Today not all big CAs obey these records, but they will pretty soon. Earlier this year The CAB Forum voted in favour of making it mandatory for all CAs by passing Ballot 187 – Make CAA Checking Mandatory. The motion states
As part of the issuance process, the CA must check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844
https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/
This change will be in effect on 8 September 2017.
CAA record format
The structure if a CAA record is as follows
<domain> CAA <flags> <tag> <value>
- flags – Octet of option bits in decimal form. Only bit 0 is used today
- tag – An ASCII string that represents the function of the record. The RFC defines three tags
- issue – Specifies that the record concerns issuance of certificates
- issuewild – Specifies that the records concern issuance of wilrdcard certificates
- iodef – url where the certificate authority can report policy violations
- value – Basically the domain of the CA allowed to issue certificates for the domain.
One example could be
# drill CAA framkant.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40373 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;; framkant.org. IN CAA ;; ANSWER SECTION: framkant.org. 300 IN CAA 0 issue "letsencrypt.org" framkant.org. 300 IN CAA 0 iodef "mailto:iodef@framkant.org"
This tells the issuing CAs that only letsencrypt are allowed to issue certificates for framkant.org and all its subdomains. The second record tells them that policy violations should be reported by email to iodef@framkant.org.
One big problem right now is that only a very few domains use this feature. To make this really powerful we need more domains to use this feature. But a big first step is to make CCA checking mandatory for all big CAs.