DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism which allows domain name holders to place administrative restrictions on the issuance of certificates for a particular domain name using a new DNS resource record.^[1][2][3] It is mandatory for publicly trusted certificate authorities to check a domain's CAA records before issuing a certificate.^[4] It is a purely administrative control, and does not prevent a malicious certificate authority from issuing fraudulent certificates. Third parties monitoring certificate authority behaviour might check newly issued certificates against the domain's CAA records, but must be aware that a domain's CAA records may have changed between the time the certificate was issued and the time the third-party checks them.

Background

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.^[5] In 2011, the certificate authorities Comodo and DigiNotar were compromised,^[6] accelerating work on various mechanisms to prevent or monitor unauthorized certificate issuance. CAA was progressively improved by the PKIX Working Group,^[7] and submitted to the IESG as RFC 6844, a Proposed Standard, in January 2013.^[1] Initially the implementation of CAA was voluntary, however in March 2017 the CA/Browser Forum voted in favor of making CAA checking mandatory for all certificate authorities by September 2017.^[4][8] At least one certificate authority, Comodo, failed to implement CAA before the deadline.^[9] A 2017 study by the Technical University of Munich found many instances where certificate authorities failed to correctly implement some part of the standard.^[10]

Protocol

CAA specifies a new DNS resource record which is used to instruct certificate authorities about the administrative restrictions placed on the issuance of certificates for a particular domain name. Certificates authorities implementing CAA are expected to perform a DNS lookup for CAA records, and ensure that a proposed certificate complies with those records prior to issuing it. Each resource record consists of a flags byte, a property tag and a property value. The flags byte defines a extensible signalling system for future use. As of 2018^[update], only the issuer critical flag has been defined, which instructs certificate authorities that they must understand the corresponding property tag before issuing a certificate.^[1] This flag allows the protocol to be extended in the future with mandatory extensions,^[10] similar to critical extensions in X.509 certificates.

As of 2018^[update], the following properties are defined:^[1]

issue

This property authorizes the holder of the domain specified in associated property value to issue certificates for the domain for which the property is published.

issuewild

This property acts like issue but allows the issuance of wildcard certificates.

iodef

This property specifies a method for certificate authorities to report to the domain name holder when a certificate is issued, or when a certificate is requested that violates the domain's security policy. As of 2018^[update], not all certificate authorities support this tag, so there is no guarantee that all certificate issuances will be reported.

Certificates authorities interpret the lack of a CAA record to allow unrestricted issuance, and the presence of a single blank issue tag to disallow all issuance.^[1]

Support

As of 2018^[update], CAA records are supported by BIND (since version 9.10.1B),^[11] Knot DNS (since version 2.2.0),^[12][13] ldns (since version 1.6.17),^[12] NSD (as of version 4.0.1),^[12][14] OpenDNSSEC,^[12] PowerDNS (since version 4.0.0),^[12] Simple DNS Plus (since version 6.0),^[12] tinydns^[12] and Windows Server 2016.^[12] Many hosted DNS providers also support CAA records, including Amazon Route 53,^[15] Cloudflare, DNS Made Easy and Google Cloud DNS.^[12]

Examples

In the following examples, assume that we want to control certificate issuance for the domain example.com. To signify that only the Let's Encrypt certificate authority can issue certificates to the domain, as well as all of its subdomains, one may use the CAA record:

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

To disallow issuance for a specific subdomain, nocerts.example.com, one would allow issuance only to an empty issuer list:

nocerts.example.com.	IN	CAA	0 issue ";"

In this case, in a request to issue a certificate to nocerts.example.com, the relevant CA will stop its search for CAA records at the subdomain.

To signify that the CA may report certificate issues or policy violations by email to caa@example.com, or through RID messages to caa.example.com, the iodef property may be applied as follows:

nocerts.example.com.	IN	CAA	0 issue ";"
nocerts.example.com.	IN	CAA	0 iodef "mailto:caa@example.com"
nocerts.example.com.	IN	CAA	0 iodef "https://caa.example.com"

If, in the original example, we would like to allow issuance to specific domains, but disallow issuance of any wildcard certificates, the issuewild property may be applied:

example.com.	IN	CAA	0 issue "letsencrypt.org"
example.com.	IN	CAA	0 issuewild ";"

The critical flag is intended for usage when future extensions of the protocol, which add new properties that may impact issuance. If, for example, a future version of CAA would include the tag "future", then the record set:

example.com.	IN	CAA	0 issue "letsencrypt.org"
example.com.	IN	CAA	128 future "Some value"

would bar a certificate authority from issuing a certificate if it does not understand how to parse the record, for instance if it has not yet updated its parsing engine to the new version.

See also

• List of DNS record types
• DNS-based Authentication of Named Entities
• HTTP Public Key Pinning
• Certificate Transparency

References