Strict CAA checking does not implement tree climbing on CNAMEs

[jsha]

@chc

e.g.

I want a cert for git.example.com

git.example.com CNAME -> gitserver.internal.example.com in the public DNS

internal.example.com has authoritative NS 10.0.0.53

Thus when LetsEncrypt follows the CNAME from git.example.com and asks the internal.example.com nameserver, it gets SERVFAIL since it cannot contact 10.0.0.53.

Re-reading your original post, I think you have an outdated view of how Let's Encrypt implements CAA. You're describing the legacy RFC 6844 with tree-climbing on CNAMEs. We used that method for a couple of weeks, but we're now back to implementing the erratum 5065 variant, which doesn't tree-climb on CNAMEs. When was the last time you got this error?

Also, your example doesn't really make sense to me: If git.example.com is a CNAME to gitserver.internal.example.com, then looking up the TXT record for DNS validation will fail because 10.0.0.53 is unreachable. Could you please show your real domain names so we can help debug further? As a reminder, all domain names in your certificates wind up in the public CT logs (e.g. at https://crt.sh/).

Thanks,
Jaco