CAA record for prevents issuance


The domain is not able to finish the verification due to CAA check. We are seeing the text below when trying to finish the validation. The TLD does have a CAA record that has only Digicert listed in it. The link here does mention that the subdomain CAA record takes precedence over the TLD. So, is there a different reason for the CAA check error here?

responseBody: a_F3j-4qk2vBk5ZMSUi_Zxlgzv-OnzrBPvjshNRteCk.-UApDbD3eQiu1uf5vf4xp-ZJv71AiycGGMuLtf06BnA
token: a_F3j-4qk2vBk5ZMSUi_Zxlgzv-OnzrBPvjshNRteCk
status: Invalid
error: CAA record for prevents issuance
validationStatus: READY
requestTimestamp: 2018-10-29T15:05:00z
validatedTimestamp: 2018-10-29T16:07:34z


Hi @sakrpa

the CAA check

doesn’t find a specific CAA policy: does not have a CAA policy. Any certificate authority can issue certificates.

This result

is curious. Looks like there is an empty entry. Checking with my own domain the CAA - entry is listed.

PS: So the entry of is used.


Subdomain CAA records take precedence when they exist. has no CAA records, so the ones from apply.


@mnordhoff Thank you for clarification. I also noticed that this domain a CNAME chain. If a domain has a CNAME chain, shouldn’t the CAA validation follow the chain and look for CAA record only for the domains it is CNAME’d to in the chain?

dig +short


It basically does the equivalent of “dig caa”, “dig caa” and “dig com caa”, stopping when it finds a CAA record set, or encounters an error.

The CAA lookup algorithm used to be more complicated, but the standard was changed.

You need to either add a CAA record set on Akamai – if you can – or change the one on


Maybe I’m wrong but as far as I can remember, it checks the CAA records in this way:

dig caa
dig caa
dig caa
dig caa
dig caa
dig com caa

It checks the origin domain, if it has CNAMES, it checks the CAA for every CNAME (but it does not perform a tree-climbing on those CNAMES as it did in Legacy CAA Implementation), if no CAA record found, it starts the tree-climbing on the origin domain, etc. till a CAA record is found, an error or till the end if there isn’t CAA records.



Right. My example left it to the DNS resolver to follow the CNAMEs.


@sahsanu: @mnordhoff’s example is more accurate here. You’ll notice in the output from dig that the recursive resolver has already snapped the CNAMEs for you and found nothing at the end:

$ dig CAA 

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> CAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54651
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 65494
;         IN      CAA

;; ANSWER SECTION:  3523    IN      CNAME    1674    IN      CNAME    498     IN      CNAME

;; Query time: 0 msec
;; WHEN: Mon Oct 29 15:21:19 PDT 2018
;; MSG SIZE  rcvd: 147

So there’s no need to run a separate dig for,, and You can just move directly on to:

dig caa
dig com caa


@jsha, I was trying to explain how Let’s Encrypt implements CAA checks because of this:

Of course, @mnordhoff example is accurate because of dig command follows CNAMEs but I wanted to show what are the steps to check the CAA records if the domain has CNAMEs… I should have used just a check domain caa, check cname caa… instead of dig command :wink:



This might be better visualized as:

dig caa
(which returns CNAME to [not relevant for CAA match]
(which returns CNAME to [not relevant for CAA match]
dig caa
dig com caa

Or something like that :wink:
CAA is not domain transitive.


I am not exactly sure what you mean by this. There is still something I am not understanding quite right. If there is no CAA record for
then isn’t there a fallback lookup to
for a default CAA policy? Or do CAA records not apply to subdomains?


Yes, there is. (And to “com”, too!)


The “original” CAA request against domain “” will never be directed to the CNAME domain.