Consider the following DNS setup of example.com:

       A                # 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.

  1. So, will the one from 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.

  1. So will the one from example.com be used for www.example.com?

(I suspect yes, see the quote above.)

  1. Is this a problem?

(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?

1 Answer 1


CAA records "climb to the root".

See §3 of RFC 8659 "DNS Certification Authority Authorization (CAA) Resource Record" which has this pseudo algorithm:

        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.

  • Thanks, this answer has several bits and pieces I was not aware of, such as the difference between RFC8659 vs. RFC6844, which may explain why some resources still explain it differently, namely, according to RFC6844; as well as the general security implementation from CNAMEs.
    – bers
    Sep 1, 2021 at 7:13
  • Regarding "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?
    – bers
    Sep 1, 2021 at 7:14
  • 1
    See in RFC8659: "Obsoletes: 6844". So 8659 is the latest version that supersedes 6844. 8659 is from November 2019 (6844 from January 2013) so hopefully everyone implements it now or soon. Note that there was an errata already for 6844 exactly for that CNAME/climb issue, see rfc-editor.org/errata/eid5065 explained in Let's Encrypt at letsencrypt.org/docs/caa Sep 1, 2021 at 7:29
  • "but "only at certificate issuance" includes re-issueance". Yes, issuance and re-issuance are the same things, same process. Sep 1, 2021 at 7:29
  • 1
    PS: soon the problem should completely disappear with 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 1, 2021 at 7:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .