Bypassing “query timed out looking up CAA for” with faulty DNS

While running certbot, the following message appears:

query timed out looking up CAA for

It appears that boulder is trying to query my DNS with a CAA record.

However, my ISP’s DNS does not support CAA, and the following command times out:

$ dig CAA
;; connection timed out; no servers could be reached

Same for:

$ dig TYPE259
;; connection timed out; no servers could be reached

(Just to be clear: It does not return an empty answer or no answer. dig times out waiting for an answer.)

A regular (A, TXT, CNAME…) query on the same DNS runs correctly:

$ dig A
(runs OK!)

I have contacted my ISP, and they have no means to fix this problem in the foreseeable future.

Because of some business related reasons, moving to a different hosting provider or switching DNS servers is currently impossible.

Can I still use letsencrypt?

(Cross posted:

@jsha - Can you recommend a solution? Thank you!!! :slight_smile:

Hi @nonZero,

The right type for CAA record is TYPE257 instead of TYPE259, in this case you should use the switch -t

$ dig -t TYPE257

Did you try the query using TCP instead of UDP?.

$ dig -t TYPE257 +tcp

If it is ok you can read this post from @jsha DNS problem: query timed out looking up CAA (using Netregistry) - #12 by jsha

They are taking a look into this UDP/TCP issue but no more news since a few days ago.

If you can't also query the CAA record using TCP, I'm afraid you won't be able to issue a cert :(. If you can query using TCP there is some hope... but maybe not in a near future... who knows ;).

Good luck,

Oops. However this fails as well. TCP also fails (it does work for A).

@jsha : How about blacklisting altogether DNS servers who never respoond to any CAA query?

Then I'm afraid you are out of lucky :frowning:

UPDATE: Since we actually need the cert for, I have added some NS records pointing to google cloud DNS! I can now get:

$ dig CAA
...	300	IN	CAA	0 issue ""	300	IN	CAA	0 issuewild "\;"


However, this does not work :frowning: :

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

 - The following errors were reported by the server:

   Type:   connection
   Detail: DNS problem: query timed out looking up CAA for

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

I was able to add the NS records for xxx, but not for the whole domain :frowning:
Why does boulder query both the subdomain and the domain? Is this a bug?

Hi @nonZero,

Indeed there is no need to create a CAA record, if you don't care about who can issue certs for your domain you can avoid to create a CAA record, the only thing Let's Encrypt needs is a DNS answer like NXDOMAIN or NOERROR. An answer of SERVFAIL or a timeout is a fail to issue your certificate.

As Let's Encrypt doesn't issue wildcard certs there is no need to create the CAA record with option issuewild.

I didn't read completely the RFC6844 nor the CABFORUM's Baseline Requirements Draft to know whether it is allowed to do want you are trying so the best answer should be provided by one of the boulder developers. @jsha, could you please be so kind to take a look into this issue?.

Edit: I forgot to comment this.

Maybe your ISP wants to know this: from 2017-Sep-8 the CAs MUST check the CAA records before they can issue a cert for the domain. CAA Records

This section is effective as of 8 September 2017.

As part of the issuance process, the CA MUST check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844, following the processing instructions set down in RFC 6844 for any records found.


1 Like

As i understand it, CAs should process CAA from left to right, as it were. If has a CAA record, there is no need to check

Boulder apparently queries and simultaneously for performance reasons:

Such a failure could be made non-fatal and maintain more or less the same security guarantees, i suppose.

(Personally, it saddens me to see Boulder growing hacks so that other people can continue neglecting their nameservers. Then again, one of the DNS providers i use used to be broken too.)

1 Like

UPDATE 2: Apparently my dig CAA did not work correctly across other servers and it needed more time to propagate. The NS records did the trick and everything works now! Thank you!


That’s what i get for only skimming the code in a language i don’t know… It already works that way, eh? If the first query works, it ignores errors in later (in sequence, not time) queries. I guess.

1 Like

It's true that Let's Encrypt only needs an NXDOMAIN or NOERROR to issue, but if that's the case, you need to return NXDOMAIN or NOERROR from every FQDN that gets looked up:,, and com. In @nonZero's case, where you want to "hide" a broken NS at, you do indeed need to create a CAA record at That will tell CA's that they can stop climbing the DNS tree when they see it.

Yep, this is correct.

1 Like

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