DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism which uses resource records in the Domain Name System (DNS) to allow domain name holders to specify which certificate authorities are authorized to issue certificates for that domain, and which types of certificates they are able to issue.^[1][2] In September 2017, the CA/Browser Forum made it mandatory for publicly trusted certificate authorities to check a domain's CAA records before issuing a certificate.^[3] CAA is specified by RFC 6844, a proposed Internet Standard written by Phillip Hallam-Baker and Rob Stradling in January 2013, which defines a new "CAA" DNS resource record type containing name-value pairs of the certificate authorities and whether they are able to issue wildcard certificates or only specific-subdomain certificates.^[1] 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 makes checks them.

History

The first draft of CAA was written by Phillip Hallam-Baker and Rob Stradling, and submitted as an IETF Internet Draft in October 2010.^[4] It was progressively improved by the PKIX Working Group,^[5] 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.^[3] At least one certificate authority, Comodo, failed to meet the deadline.^[6]

Protocol

CAA uses DNS resource records to instruct certificate authorities 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 they comply with those records prior to issuing a certificate. 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 both mandatory and optional extensions, with some assurance that if a certificate authority cannot understand the implications of the mandatory extention, it will at the very least fail-closed. This is similar to how critical extensions in X.509 certificates work.

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 restrict all issuance.

Support

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

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