Consider the following DNS setup of example.com
:
A 89.41.169.49 # 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
. However, 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.com
be used for www.example.com
?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 example.com
for www.example.com
.
So assume "no" in the following.
example.com
be used for www.example.com
?(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
So if 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.
As for:
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.
CNAME
s. — Sep 01, 2021 at 07:13 CAA
records 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/HTTPS
records that would remove the need to do a CNAME
at all. Hence the CAA
resolution path and the service resolution path will become completely separate. — Sep 01, 2021 at 07:35 External links referenced by this document: