DNS problem: query timed out looking up A

Help
1

My domain is: climbthecurve.com

I ran this command: sudo certbot --apache certonly -d climbthecurve.com -d www.climbthecurve.com

It produced this output:

Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for climbthecurve.com
http-01 challenge for www.climbthecurve.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. climbthecurve.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: dns :: DNS problem: query timed out looking up A for climbthecurve.com, www.climbthecurve.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: dns :: DNS problem: query timed out looking up A for www.climbthecurve.com

IMPORTANT NOTES:

My web server is (include version): Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version): CentOS 7.0 x64

My hosting provider, if applicable, is: Digital Ocean

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): 0.31.0

My nameservers are:

Name Server: DNS1.ACCESSUS.NET
Name Server: DNS2.ACCESSUS.NET

Thanks,
Chaz

2

I think the domain’s DNS service might be having issues?

E.g. https://unboundtest.com/ works perfectly, but DNSViz says some queries timed out.

https://unboundtest.com/m/A/climbthecurve.com/JGVLQ6F3
https://unboundtest.com/m/A/www.climbthecurve.com/OWGKSI4H

http://dnsviz.net/d/climbthecurve.com/XJf8pA/dnssec/
http://dnsviz.net/d/www.climbthecurve.com/XJf80w/dnssec/

Maybe there are routing issues, or they rate-limit queries.

1 Like
3

Any suggestions on what to tell/ask the DNS to do? Just wait and see?

4

Hi @ChazDazzle

both nameservers have fatal timeouts:

X Fatal error: Nameserver doesn't support TCP connection: dns1.accessus.net / 209.145.150.10: Fatal error (-14). Details: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
X Fatal error: Nameserver doesn't support TCP connection: dns2.accessus.net / 209.145.176.20: Fatal error (-14). Details: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
1 Like
5

I guess. You could contact your provider and ask if they have any known issues, or if they implement heavy rate limiting.

Let's Debug also showed issues.

Let's Debug makes DNS queries from the same IP addresses as the letsdebug.net website runs on. If your provider could run mtr, or check their logs...?

Good catch. Still... I don't think any of the queries involved in this would use TCP.

1 Like
6

I tried doing a packet capture on the Let's Debug server.

This is one query that's timing out:

timeout
timeout1920×1043 210 KB

Moreover, those nameservers seem to be entirely dropping any kind of traffic from Let's Debug right now:

root@letsdebug:~# ping 209.145.150.10
PING 209.145.150.10 (209.145.150.10) 56(84) bytes of data.
^C
--- 209.145.150.10 ping statistics ---
69 packets transmitted, 0 received, 100% packet loss, time 69637ms

(whereas ICMP Echo works from any other server).

So I would agree that this seems like an overzealous firewall or rate limiting.

And I don't think it's a routing issue, as there's a pretty reproducible cycle:

  • Queries and ICMP echo work
  • Begin the Let's Debug test
  • Around 5 seconds in, dns1.accessus.net starts dropping all traffic
  • Recovers 5-10 minutes later
2 Likes
7

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