Amazon Route 53/CloudFront Fails CAA Check


#1

Hi all,

While trying to generate a certificate for CloudFront, I’m now receiving an error informing the CAA check has failed, as there isn’t a record present just yet. Three months ago while renewing, and every time previously, there haven’t been any issues. After searching around it seems like the CAA check is relatively new in letsencrypt, but I couldn’t find any mention if it’s a requirement yet, as it didn’t seem to a requirement just a few months ago.

I’m using Amazon Route 53 for DNS, and unfortunately it doesn’t support adding a CAA entry just yet, so would the only other option be to use a different DNS service, preferably one where I can edit the zone file manually, until Amazon enables this feature? I can access my CDN just fine without SSL.

Here’s the output while attempting to generate the certificate:

# certbot certonly --manual -d i.ncdn.moe

Failed authorization procedure. i.ncdn.moe (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up CAA for i.ncdn.moe

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: i.ncdn.moe
   Type:   connection
   Detail: DNS problem: SERVFAIL looking up CAA for i.ncdn.moe

#2

CAA records are not mandatory. A response that indicates no CAA records exists would be accepted.

Most issues with CAA SERVFAILs are due to non-standards-compliant DNS server. Route 53 generally has shown no issue like this in the past, and if you check this recent thread, multiple people report issuance works on domains behind Route 53. That said, other DNS issues, such as DNSSEC misconfigurations, can cause SERVFAIL to occur. You can try this tool, which uses a DNS configuration similar to Let’s Encrypt, with your real domain and review the log output.

A more specific answer would require your real domain in order to run the tests.


#3

Thanks for the reply, I’ve updated my original post to reflect the actual domain details.

If I attempt to use dig to query for type257, it appears to return “status: NOERROR” - could I be missing anything else? I haven’t changed any configuration, and it was working as intended 3 months ago, so I can’t imagine what might have happened.

$ dig i.ncdn.moe type257

; <<>> DiG 9.11.1-P3 <<>> i.ncdn.moe type257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24397

#4

dnsviz reports a number of issues for this domain. You can compare the results to this working domain behind Route 53.

I noticed that there are no name servers set for your parent domain, similar to this thread. I don’t think that’s a valid DNS configuration, and some of the errors might be due to this.


#5

The Route 53 zone is called i.ncdn.moe but there doesn’t seem to be any zone for ncdn.moe.

That’s not a valid setup in the DNS. Due to how DNS resolution works, such an invalid delegation is usually, mostly functional. It’s not functional for Let’s Encrypt’s explicit query for a CAA record for ncdn.moe .

Coincidentally, someone else had the same problem, with a different DNS service and for different reasons, earlier today:

You need to create an ncdn.moe zone in Route 53. (Or any other DNS provider, really, but why make it more complicated?)

Then you’d create i record(s) to replicate the current setup. (Either equivalent CloudFront alias record(s), or – for the complicated option – NS records to delegate to the existing zone.)

(Due to how Route 53 works, an ncdn.moe zone would inevitably have different nameservers than your existing i.ncdn.moe zone, so you’d have to adjust the delegation at your registrar.)


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.