DNS problem: query timed out looking up CAA

My domain is: pp.myplan.on.bluecross.ca

I am using cert-manager to provision Let’s Encrypt certificates in my Kubernetes cluster using the ACME DNS Challenge. For some reason the authorization is failing with the following error: DNS problem: query timed out looking up CAA for pp.myplan.on.bluecross.ca

When I run dig pp.myplan.on.bluecross.ca caa I have the following result:

;; QUESTION SECTION:
;pp.myplan.on.bluecross.ca.	IN	CAA

;; ANSWER SECTION:
pp.myplan.on.bluecross.ca. 3599	IN	CNAME	bluecross.demo.direct.getbreathe.life.
bluecross.demo.direct.getbreathe.life. 29 IN CNAME o-breathelife-prod2-reblaze-com.breathelife.prod2.reblaze.com.
o-breathelife-prod2-reblaze-com.breathelife.prod2.reblaze.com. 60 IN CAA 0 issue "letsencrypt.org"

A few things to note:

  1. We are generating a certificate for our client, as we do not own the bluecross.ca domain nor operate the DNS for that domain. Hence we have a CNAME in place to our domain (getbreathe.life). We in turn have a CNAME to Reblaze subdomain, which is a Cloud WAF vendor.
  2. Our client is using a DNS server that does not support CAA records.
  3. Reblaze is using the ACME HTTP Challenge to generate certificates on its side and it works.

Any help would be greatly appreciated.

Hi @fallard84

checking your domain there is a new Letsencrypt certificate, 6 days old - https://check-your-website.server-daten.de/?q=pp.myplan.on.bluecross.ca#ct-logs

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2020-02-05 2020-05-05 bluecross.demo.direct.getbreathe.life, pp.myplan.on.bluecross.ca - 2 entries duplicate nr. 1

Please use that instead of creating a new certificate.

Looks like the CAA problem is only a temporary problem.

Hi @JuergenAuer,
Yes, there is a fresh certificate that was generated by Reblaze using the HTTP challenge and which is deployed on the Load balancer of Reblaze since this is fronting our application. But we need to also have a certificate on the upstream server that Reblaze is calling. I want to have certificate on the upstream server to be valid for the same domains in case we need to disable Reblaze and redirect all traffic to our server directly.

Reusing the certificate deployed in Reblaze is doable but would require manual intervention, which goes against the purpose of using Lets Encrypt :slight_smile:

You say that the CAA is a temporary problem, is that something that was communicated by Let’s Encrypt or this is just an assumption on your part?

Generally, the timeout issue is temporary. I assumed this because now unboundtest can correctly identify the CAA record.
https://unboundtest.com/m/CAA/pp.myplan.on.bluecross.ca/R7ECC2YE

Can you try this again and see if the error persists?

Thank you

CAA is always checked. So if you have a 6 days old certificate, the CAA check had worked -> looks like a temporary problem.

I tried multiple times since yesterday evening and I consistently get this error. I tried again 2 mins ago.
For now I have a generated a partial certificate (only valid for my getbreathe.life subdomain) on my upstream server since it was expiring on Feb 16th. I created another order for a certificate with both domains and I will monitor again in the upcoming days to see if it does eventually resolve correctly.

Hi @fallard84,

I can reproduce this problem when I try to query the nameservers listed for on.bluecross.ca:

$ dig on.bluecross.ca NS

<snipped>
on.bluecross.ca.	3599	IN	NS	v2dns01p.canassurance.net.
on.bluecross.ca.	3599	IN	NS	v4dns01p.canassurance.net.
$ dig @v2dns01p.canassurance.net -t CAA pp.myplan.on.bluecross.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @v2dns01p.canassurance.net -t CAA pp.myplan.on.bluecross.ca
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig @v4dns01p.canassurance.net -t CAA pp.myplan.on.bluecross.ca

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @v4dns01p.canassurance.net -t CAA pp.myplan.on.bluecross.ca
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Can you contact the administrators of that zone and the two nameservers to ask that they investigate the problem?

2 Likes

I’m able to repro the timeout with the on.bluecross.ca nameservers using Unboundtest too: https://unboundtest.com/m/CAA/on.bluecross.ca/B25NU2IJ

Recall that because of CAA processing rules when performing CAA lookups that these nameservers need to be able to respond to CAA queries when a CAA record isn’t encountered for pp.myplan.on.bluecross.ca or myplan.on.bluecross.ca.

1 Like