Can someone here explain to me exactly what CAA I am supposed to add to my BIND configuration so as to allow only Let’s Encrypt to issue certificates for me? I was quite confused by the RFC. I would also like to specify the critical flag in my DNS CAA Records.
I use this:
example.org. CAA 1 issue “letsencrypt.org"
example.org. CAA 1 iodef "mailto:caa@example.org”
Andreas
2 Likes
This is correct and should be all you need.
FYI, iodef is not (yet) supported by Let's Encrypt.
The critical flag in CAA, like the critical flag in x509 extensions, means only "error out if you don't understand this." Adding the critical flag to CAA types that are part of the base RFC (like issue) has no effect.
Also keep in mind: I'm not aware of any other CA that implements CAA yet. So, while adding the entries is nice, keep in mind that most other CAs will be willing to issue for your domain regardless. Edit: As of September 2017, all public CAs are required by the Baseline Requirements to implement CAA.
3 Likes
Sorry for the newb question, BUT is the CAA record just another TXT record in the DNS space ?
Also, are the double quotation marks mandatory ?
My DNS provider doesn't seem to allow these.
TIA's
No, it's a new record type, CAA. It's not a TXT record.
Ultimately that's up to whatever software is parsing your records. RFC 6844 section 5.1.1 suggests that it be considered an RFC 1035 character-string, in which case the quotes are usually optional.
This is actually wrong. According to the RFC the critical bit is the leftmost bit, i.e. the value you should be using is 128, not 1.
3 Likes
Hello TCM,
rereading RFC 6844: You’re right!Thanks!
https://tools.ietf.org/html/rfc6844#section-5.1 is very clear about the Flag
-> “Issuer Critical Flag” not set:
example.org. CAA 0 issue “letsencrypt.org"
example.org. CAA 0 iodef "mailto:caa@example.org”
-> “Issuer Critical Flag” set:
example.org. CAA 128 issue “letsencrypt.org"
example.org. CAA 128 iodef "mailto:caa@example.org”
using 1 as Issuer Critical Flag result in "other bits have to be ignored"
and will be interpreted as "“Issuer Critical Flag not set” by a conforming implementation.
I’ll update my domains 
1 Like
Can someone clarify the proper usage here with issue and iodef for letsencrypt? Values of 0 or 128? And should both be set? Google is using 0 as the value and does not have iodef set. What is the proper usage?
$ dig +short -t caa google.com
0 issue “symantec.com”
“0” means the CA may continue to issue the the certificate if it does not understand the record. It’s like a non-crtiical X.509 extension.
“128” means the CA may not issue the certificate if it does not understand the record in question, so this would be like a critical X.509 extension.
That’s not to say that a CA who does not implement CAA at all will be affected in any way. This is just for CAs who already implement CAA in some way.
Let’s Encrypt will also interpret decimal “1” as a critical flag since this is a common misreading of the CAA RFC. Either way, decimal “128” would be the correct choice (and hopefully the one that’s compatible with all CAA implementations).
The iodef record can be used by CAs to report issuance attempts that failed to meet the CAA policy of a site to the site itself (via email or a web service). Let’s Encrypt currently does not support iodef, but you can create the record anyway for other CAs who do support it (note: I’m not sure if any do). As long as the record is marked as non-critical (0), Let’s Encrypt will continue to issue certificates.
The easiest option would probably be to use SSLMate’s CAA Record Generator, which provides the correct format for various DNS implementations.
Why? 
You shouldn't violate the RFC to accomodate people who violate the RFC. Fail hard and get everyone to fix their stuff. RFCs exist for a reason. (That is assuming there is a provision in the RFC to fail hard. I didn't look right now.)
1 Like
I would generally agree, except that the behaviour here is to err on the side of being stricter than necessary (i.e. interpret the value to mean “critical”) when the RFC-compliant behaviour would be to ignore the value (“Applications that interpret CAA records MUST ignore the value of all reserved flag bits.”) I’d definitely be up in arms if it’d be the other way around. 
The only downside is that the (reserved) bit 7 cannot be used without possibly causing compatibility issues. Probably not a big deal since we still got 6 other bits to go through before that’s relevant. Hopefully whoever works on future CAA-related RFCs will remember this tidbit.
@bgroper Eventually, RFC3597 does the trick, if your setup does not support CAA ressource records yet.
I’ve always noticed on Qualsys SSL Labs test that it says DNS CAA NO.
I added a CAA record for my domain and the Qualsys test still says NO … am I on the right track here or am I not understanding something about DNS CAA ???
AIUI if your domain has a CAA record, that output should change. Perhaps there’s some caching involved. Would you mind sharing the domain in question?
Example of a domain with a CAA record:
https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com
Thanks for all the replies, I figured out the problem, I was still running bind 9.9.5 because the server was still on Ubuntu 14.04. That record only was introduced after 9.9.6. Did a distro upgrade to 16.04.2 this morning with only a few minor headaches getting bind9 to start, but an hour later and now Qualsys picks up the CAA record.
Now to upgrade my secondary DNS server to 16.04.2, this one now should only take me 20 minutes to have all the bind9 start issues sorted.
Just updated my secondary to 16.04.2 … took me all of 22 minutes, all sorted now.
Just a heads up for anyone upgrading the Ubuntu from 14.04 to 16.04, there appears to be a problem caused with logging settings in named.conf not being correct for the new version 9.10.3-P4-Ubuntu. It causes the bind9 service to fail when starting up. Just comment out all logging settings in named.conf and the service will start up fine, I now need to go and dig to find what the new logging settings formats and permissions are but that is what caused the upgrade of my primary to take me well over an hour, was getting the bind9 service to start up.
1 Like
I wonder if any additional values, like ; account=123456 are supported. I would love to limit not only CA domain but also LE account id or some kind of public key so that nobody can simply register another account and get certificates for my domain…
An RFC that allows you to bind CAA records to ACME accounts is being worked on (and is in WG last call, IIRC).
This is the relevant issue in boulder (the CA software behind Let’s Encrypt), in case you want to track progress:
Another potentially interesting extension to CAA would be the option to ask that issuers rely only on certain of the 10 Blessed Methods. This allows a subscriber to effectively distrust methods based on their particular circumstances or just an understanding of the limitations of each method. This would not have been possible when CAA was conceived because the Blessed Methods had not been explicitly enumerated and in practice most CAs performed “any other method” validations by the old rules.
Setting CAA to require a DNS-based validation method, combined with DNSSEC for your DNS records including CAA should ensure that bad guys can’t obtain a certificate for your names without attacking either your secure DNS, or the secure DNS of a domain above yours (e.g. your TLD or the root). This is a higher bar than is achievable today by any merely technical means.
This approach could be simulated today by a CA (e.g. Let’s Encrypt) setting aside some sub-domains for particular Blessed Methods (or as an ACME implementation, particular ACME challenges). We could imagine that if a CAA record were to specify http-01.letsencrypt.org as issuer that would signify that only the http-01 challenge should be used with that domain for example.