CAA Record: Is it worth it?

[tialaramex]

@petercooperjr

I suspect that the reason people see CAA errors is just that CAA is the first DNS record checked, and if the issue is a buggy authoritative DNS server or misconfigured DNSSEC or whatnot, that if CAA wasn't checked you'd just see the error when trying to resolve the TXT or AAAA/A record for the challenge. Maybe I'm wrong on the ordering, though?

The DNS standard is very clear that the only correct thing for a server that's authoritative for somename.example to do when asked somename.example FOOZLE? and it has no idea what FOOZLE is but somename.example exists will be to say there are zero answers OK.

However, despite that it appears several semi-popular commercial DNS server products exist which get this (and other things) wrong. They answer A? and these days often AAAA? correctly but they get a lot more wrong, likely including problems when asked CAA? still today's web browsers mostly ask A? and AAAA? so just getting those correct is enough to seem like your server "works" for a not very inquisitive customer and once the customer has purchased the product who cares if it works right?

Because DNS is so essential it is critical that it's implemented correctly, down the road from here for example HTTP/3 deployment is expecting to depend heavily on HTTPS/ SVCB records in DNS, obviously a server that can't answer CAA? correctly is not going to get that right either. But in a web browser it's OK to just race and measure - your browser may conclude your network is too broken to bother trying HTTP/3 so you get the HTTP/2 or even HTTP/1.1 protocol and things are a little slower but it works. Let's Encrypt is forbidden from just assuming your server is broken and passing along, your server must know how to answer CAA? and unfortunately a minority still can't get that right in 2020 even though a compliant 1990s DNS server would have correctly reported "zero answers OK".

[bruncsak]

@JamesLE

The CAA check is potentially a series of queries all the way up the hierarchy.

Sorry, a bit off topic.

I have to point out that I like the idea of the security feature what the CAA record is providing. The owner of the domain specifies which CA is allowed to issue certificate for the given domain. I love it.

But...

After all this preamble, I must tell my opinion that the DNS lookup traversal for the CAA record is a very-very bad idea. I consider the RFC being broken.

I would like to have a different CAA standard specification without DNS traversal. By that (incompatible for sure) specification, the CA just simply looks up the CAA record of the actual domain name for which the certificate is to be issued, to know its own permission for issuing the certificate.

[petercooperjr]

@bruncsak

I would like to have a different CAA standard specification without DNS traversal. By that (incompatible for sure) specification, the CA just simply looks up the CAA record of the actual domain name for which the certificate is to be issued, to know its own permission for issuing the certificate.

That would certainly make things simpler on the CA side, but then I as a domain owner need to ensure that every time I add a subdomain that I add a CAA record for it. It gets even trickier if I'm using DNS-01 challenges to get certificates for accessible-only-on-my-network devices, since then rather than just automating the DNS challenge as needed I need to leave a CAA record out there indefinitely for each one. All solvable problems, sure, but it's a whole lot easier to just put a CAA record at my main domain name level for my entire organization and be done with it.

But checking CAA all the way up to the TLD level, so that a misconfiguration on .com would stop all certificate issuance under it for anyone who hadn't established their own CAA record? That does seem rather… weird.

There's probably no perfect answer, and the existing standard has all the advantages of being done by a committee of interested parties and all the disadvantages of being done by a committee.