Operation timed out

Help
1

My domain is: rc.fas.harvard.edu

I ran this command: certbot certonly --dns-rfc2136 --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini -d 'dc-le-test.rc.fas.harvard.edu'

It produced this output:
Requesting a certificate for dc-le-test.rc.fas.harvard.edu
Encountered exception during recovery: certbot.errors.PluginError: Encountered error when making query: The DNS operation timed out.
Encountered error when making query: The DNS operation timed out.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): apache 2.4.6

The operating system my web server runs on is (include version): CentOS 7.9.2009 (Core)

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.32.0

I have set up my own DNS server for this, and I believe it is not being blocked at the networking level. I can connect to it on port 53 from everywhere that I've tried. I'm assuming this is a BIND config error, but if you are able to add any information from your end that may help locate the problem, that would be much appreciated.

Thank you.

1 Like
2

Yes; you have reached the Rate Limits.

Testing and debugging are best done using the Staging Environment.

image
image1088×843 15.5 KB

image
image1096×879 16.7 KB

1 Like
3

While problematic on its own of course, it should not cause the "The DNS operation timed out." though.

3 Likes
4

Doesn't seem to be a DNS Name Server for the domain name.

$ nslookup
> dc-le-test.rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
> set q=soa
> dc-le-test.rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
> set q=ns
> dc-le-test.rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
>

$ nslookup
> rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   rc.fas.harvard.edu
Address: 140.247.64.140
> set q=soa
> rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
rc.fas.harvard.edu
        origin = iliaddns.rc.fas.harvard.edu
        mail addr = rchelp.fas.harvard.edu
        serial = 0
        refresh = 28800
        retry = 7200
        expire = 2419200
        minimum = 86400

Authoritative answers can be found from:
> set q=ns
> rc.fas.harvard.edu
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
rc.fas.harvard.edu      nameserver = iliaddns.rc.fas.harvard.edu.
rc.fas.harvard.edu      nameserver = iliaddns2.rc.fas.harvard.edu.

Authoritative answers can be found from:
> server iliaddns.rc.fas.harvard.edu
Default server: iliaddns.rc.fas.harvard.edu
Address: 140.247.232.232#53
> set q=a
> dc-le-test.rc.fas.harvard.edu
Server:         iliaddns.rc.fas.harvard.edu
Address:        140.247.232.232#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
> set q=ns
> dc-le-test.rc.fas.harvard.edu
Server:         iliaddns.rc.fas.harvard.edu
Address:        140.247.232.232#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
> set q=ns
> dc-le-test.rc.fas.harvard.edu
Server:         iliaddns.rc.fas.harvard.edu
Address:        140.247.232.232#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
> set q=aaaa
> dc-le-test.rc.fas.harvard.edu
Server:         iliaddns.rc.fas.harvard.edu
Address:        140.247.232.232#53

** server can't find dc-le-test.rc.fas.harvard.edu: NXDOMAIN
>
1 Like
5

That's an interesting problem that I didn't know we were having. Thank you for bringing that to my attention.

2 Likes
6

Regarding the nslookup results, this is not a publicly accessible webserver. I intentionally set it up that way to test this rfc2136 method of certificate creation. Would that explain what you're seeing? And would that be expected?

7

The error "The DNS operation timed out" does suggest Certbot can't reach your DNS server. Make sure UDP as wel as TCP can be used.

3 Likes
8

That was indeed the problem. Sorry I didn't catch that. I have a new error now, but that's progress.

[root@dc-le-test ~]# certbot certonly --dns-rfc2136 --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini -d 'dc-le-test.rc.fas.harvard.edu'

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Requesting a certificate for dc-le-test.rc.fas.harvard.edu

Encountered exception during recovery: certbot.errors.PluginError: Unable to determine base domain for _acme-challenge.dc-le-test.rc.fas.harvard.edu using names: ['_acme-challenge.dc-le-test.rc.fas.harvard.edu', 'dc-le-test.rc.fas.harvard.edu', 'rc.fas.harvard.edu', 'fas.harvard.edu', 'harvard.edu', 'edu'].

Unable to determine base domain for _acme-challenge.dc-le-test.rc.fas.harvard.edu using names: ['_acme-challenge.dc-le-test.rc.fas.harvard.edu', 'dc-le-test.rc.fas.harvard.edu', 'rc.fas.harvard.edu', 'fas.harvard.edu', 'harvard.edu', 'edu'].

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

[root@dc-le-test ~]#

1 Like
9

That is fine, however its Authoritative DNS Name Servers need to be publicly accessible and supply the answers needed by the DNS-01 challenge.

1 Like
10

Ok, thank you. I will work to fix that.
I appreciate the help.

2 Likes
11

I'm not sure what this error means exactly, but it could be due to an incorrect zone configuration. Maybe the BIND logs can shed some light on this, although my experience with BIND and (debug) logging is that it is (#&$.

3 Likes
12

OR
They can also return a set of delegated nameservers for said subdomain.
[which in turn must be accessible and either answer the question OR delegate it ...]

3 Likes
13

I have a couple of questions about the error that I was receiving, but before I take your time with those, I wanted to find out if the rate limit error mentioned earlier will make them moot.

The error message associated with the rate limit seems pretty clear that there's nothing that can be done about the 50 certificate limit. Is that correct? We'd need to continue to keep our total number of certificates under 50 per week for the entire harvard.edu domain? I ask because we were hoping to use the DNS verification to install certs on even more hosts.

14

Not exactly, see Overrides in Rate Limits - Let's Encrypt
although the process takes time.

1 Like
15

Thank you for the clarification. This would, however, be for the entire harvard.edu domain, correct? I ask because we are one small department at the university (rc.fas.harvard.edu) and we have no way to ensure that other departments under the harvard.edu domain will do their part to stay within any limits set.

16

@lestaff suggestions please for @daniel1 on Rate Limit Overrides for Educational institution harvard.edu.

17

Not exactly.
Renewals are not counted towards that limit.
Every active cert can be renewed.

2 Likes
18

Oh, sorry that I was misunderstanding that. That would certainly help as we wouldn't be adding 50 new certificates per week. Unfortunately, I still would have no way of knowing if other departments at the university would push the entire harvard.edu domain over the limit. So that may still pose a problem.

1 Like
19

Feel free to fill out the rate limit form as best you can and LE staff and you can discuss in the resulting ticket

4 Likes
20

Thank you @mcpherrinm. :slight_smile:

1 Like