CAA, or Certificate Authority Authorization, provides a way to designate which CAs are allowed to create a Certificate for specific domains. This is done accomplished by publishing new
caa DNS records, with three directives:
iodef. For example:
$ dig craigslist.org caa craigslist.org. 300 IN CAA 0 issue "digicert.com" craigslist.org. 300 IN CAA 0 iodef "mailto:firstname.lastname@example.org" -^-
0 value in the record indicates the Flags for the record. At the moment, only two values are defined:
0 - Understanding this CAA record is optional
128 - Understanding this CAA record is critical
RFC 6844 specifies this regarding the Critical flag:
Flags: One octet containing the following fields: Bit 0, Issuer Critical Flag: If the value is set to '1', the critical flag is asserted and the property MUST be understood if the CAA record is to be correctly processed by a certificate issuer. A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property tag that for which the issuer critical flag is set.
And earlier provides this as an example:
The critical flag is intended to permit future versions CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains. In the following example, the property 'tbs' is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless the processing rules for the 'tbs' property tag are understood. $ORIGIN example.com . CAA 0 issue "ca.example.net; policy=ev" . CAA 128 tbs "Unknown"
In all my browsing around, I've only see the flag set to
0 ... with one exception:
$ dig stackoverflow.com caa stackoverflow.com. 300 IN CAA 0 issue "digicert.com" stackoverflow.com. 300 IN CAA 0 issue "letsencrypt.org" stackoverflow.com. 300 IN CAA 0 issuewild "digitcert.com" stackoverflow.com. 300 IN CAA 0 issuewild "letsencrypt.org" stackoverflow.com. 300 IN CAA 128 iodef "mailto:email@example.com" -^^^-
iodef directive has a flag of
Presumably, what this means is if a CA (not specified in the
issuewild directives) is asked to create a certificate for "stackoverflow.com" and does not understand the
iodef record, they MUST NOT create the certificate.
But if they do not understand
iodef, they likely do not understand
issuewild (as all 3 are specified in the original CAA RFC. Which means they are likely to just issue the certificate.
If they DO understand the CAA RFC, then they understand all three directives, and would send the violation e-mail either way.
If Stackoverflow had set all of their CAA records to
128, I wouldn't have thought much of it. But the fact that only the
iodef record has the critical flag turned on confused me. What benefit is there to turning on the critical flag on just the
iodef record, but not
To avoid this being speculative, I just want to clarify my question is not "Why did Stackoverflow choose to this". Instead, it is a generic "Why would anyone choose to do this, i.e., what is the purpose of this"
Late answer, but still relevant. The current CAA RFC is RFC 8659, which has some additional information on the Critical Flag.
It does still not answer the question why someone would choose for this exact setup, so the critical flag to 0 for
issuewild directives, but 128 for the
iodef record. I basically see two situations where such configuration makes sense:
Like every service provider, CA's might implement CAA incorrectly. It is unlikely, but it happens.
issuewild are clearly the core of CAA, not supporting these tags is equal to not supporting CAA at all.
iodef, on the other hand, is an addition: not only do we block CAA requests when the CA is not allowlisted, but we also alert the user about the fact that we got blocked. Maybe, some CA that is in the process of implementing CAA, implements the core tags first, and adds
iodef later on. This is of course speculation. The outcome of setting 128 to all CAA records would do not change the outcome, but StackOverflow considers the support of the
iodef directive, thus the sending of alert e-mails, critical. Ironically, not supporting the
iodef record would of course lead to no alert e-mail be sent, and like you said, not supporting CAA at all would lead to the issuing of the certificate. That is why we must hope CAA support will be a strict requirement for being a CA.
A future CAA version might overwrite, change or replace the
iodef directive because they have decided on a new alert method that has become more popular than e-mail. The current setting marks the current
iodef as critical, and thus indicates that the record should be successfully parsed, or the CA should deny. If the specs change in regards to
iodef should be handled, the CA has to deny the certificate if it cannot handle this old
That being said, it is still unlikely this will really make a huge difference. But that accounts for the CAA record as a whole, it is really a security-in-depth measure that is more likely to alert on misconfiguration than have a large impact on security.
External links referenced by this document: