Information Security
certificates dns caa
Updated Fri, 02 Sep 2022 15:22:27 GMT

Are problems expected when a subdomain CNAME target has no CAA record?

Consider the following DNS setup of

       A                # this is for
       CAA     0 issue ""
www    CNAME

If I have understood correctly everything I read (in particular,, the CAA for is taken from the one for However, does not have a CAA record, and Google does not use Let's Encrypt.

Edit: I just noticed that that while does not have a CAA, does have one.

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

So assume "no" in the following.

  1. So will the one from be used for

(I suspect yes, see the quote above.)

  1. Is this a problem?

(I guess yes.)

If so, let's go one step further: assume does use a CAA record at one point, and all is fine. When the admins of 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 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:

        while domain is not ".":
          if CAA(domain) is not Empty:
            return CAA(domain)
          domain = Parent(domain)
        return Empty

So if CAA returns empty result, the client (which is typically the CA) is expected to issue 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 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.

Comments (5)

  • +0 – 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. — Sep 01, 2021 at 07:13  
  • +0 – 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? — Sep 01, 2021 at 07: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 explained in Let's Encrypt at — Sep 01, 2021 at 07:29  
  • +0 – "but "only at certificate issuance" includes re-issueance". Yes, issuance and re-issuance are the same things, same process. — Sep 01, 2021 at 07: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 01, 2021 at 07:35