DNS problem: query timed out looking up A


#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.


#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

#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.

https://letsdebug.net/climbthecurve.com/30142
https://letsdebug.net/www.climbthecurve.com/30143

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.


#6

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

This is one query that’s timing out:

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

closed #7

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