Consider the following DNS setup of
A 184.108.40.206 # this is for redirect.pizza CAA 0 issue "letsencrypt.org" www CNAME ghs.googlehosted.com
If I have understood correctly everything I read (in particular, https://serverfault.com/q/885952/), the CAA for
www.example.com is taken from the one for
ghs.googlehosted.com does not have a CAA record, and Google does not use Let's Encrypt.
Edit: I just noticed that that while
ghs.googlehosted.com does not have a CAA,
googlehosted.com does have one.
googlehosted.combe used for
I believe, no:
If a domain name is a CNAME (also known as an alias) for another domain, then the certificate authority looks for the CAA record set at the CNAME target (just like any other DNS lookup). If no CAA record set is found, the certificate authority continues searching parent domains of the original domain name.
This is also in line with SSL Labs displaying the CAA for
So assume "no" in the following.
example.combe used for
(I suspect yes, see the quote above.)
(I guess yes.)
If so, let's go one step further: assume
ghs.googlehosted.com does use a CAA record at one point, and all is fine. When the admins of
ghs.googlehosted.com delete their CAA entry at one point, thinking that this will relax requirements - will this effectively make the requirements stricter, as now the one from
example.com is used?
CAA records "climb to the root".
See 3 of RFC 8659 "DNS Certification Authority Authorization (CAA) Resource Record" which has this pseudo algorithm:
RelevantCAASet(domain): while domain is not ".": if CAA(domain) is not Empty: return CAA(domain) domain = Parent(domain) return Empty
www.example.com CAA returns empty result, the client (which is typically the CA) is expected to issue
example.com CAA and then it stops there as the results won't be empty based on your example.
There is no reason to continue anything at the name towards which the CNAME points to, things stay with the original domain name.
This is spelled out in details at 7 of that document:
This document obsoletes [RFC6844]. The most important change is to the "Certification Authority Processing" section (now called "Relevant Resource Record Set" (Section 3), as noted below). [RFC6844] specified an algorithm that performed DNS tree-climbing not only on the FQDN being processed but also on all CNAMEs and DNAMEs encountered along the way. This made the processing algorithm very inefficient when used on FQDNs that utilize many CNAMEs and would have made it difficult for hosting providers to set CAA policies on their own FQDNs without setting potentially unwanted CAA policies on their customers' FQDNs. This document specifies a simplified processing algorithm that only performs tree-climbing on the FQDN being processed, and it leaves the processing of CNAMEs and DNAMEs up to the CA's recursive resolver.
When the admins of ghs.googlehosted.com delete their CAA entry at one point,
CAA records are checked only at certificate issuance, by the certificate authority, and never after.
Other than that, for any cases, not just
CAA, when you have
CNAME pointing to external resources not under your control you indeed kind of leave some control of your DNS tree to those resources so it can have side effects. Which boils down to monitoring what those are doing and removing any records you don't need to avoid dangling records that can be vulnerabilities yielding to a full blown takeover.
CNAMEs. — Sep 01, 2021 at 07:13
CAArecords are checked only at certificate issuance, by the certificate authority, and never after.": yes, I was aware of that, but "only at certificate issuance" includes re-issueance, I guess - so you are not on the safe side just because a certificate has been issued successfully at initial setup, right? — Sep 01, 2021 at 07:14
SVCB/HTTPSrecords that would remove the need to do a
CNAMEat all. Hence the
CAAresolution path and the service resolution path will become completely separate. — Sep 01, 2021 at 07:35
External links referenced by this document: