During secondary validation: DNS problem: query timed out looking up A for www.harrychapinfoodbank.org","status":400}

My domain is: harrychapinfoodbank.org

I ran this command: ee site ssl harrychapinfoodbank.org --debug

It produced this output:
Debug: ----------------------- (0.03s)
Debug: COMMAND: cd /opt/easyengine/services && docker ps -q --no-trunc | grep $(docker-compose ps -q global-nginx-proxy) (0.031s)
Debug: STDOUT: a258c7f19b7e76e91b0149d9584e0c7f478196e7faad958ff9991216beee0584
(0.628s)
Debug: RETURN CODE: 0 (0.628s)
Debug: ----------------------- (0.628s)
Debug: ----------------------- (0.628s)
Debug: COMMAND: docker ps > /dev/null (0.628s)
Debug: RETURN CODE: 0 (0.679s)
Debug: ----------------------- (0.679s)
Debug: ----------------------- (0.679s)
Debug: COMMAND: command -v docker-compose > /dev/null (0.679s)
Debug: RETURN CODE: 0 (0.681s)
Debug: ----------------------- (0.681s)
Debug (bootstrap): Using default global config: /opt/easyengine/config/config.yml (0.688s)
Debug (bootstrap): No project config found (0.689s)
Debug (bootstrap): argv: /usr/local/bin/ee site ssl harrychapinfoodbank.org --debug (0.689s)
Debug (bootstrap): Running command: site (0.689s)
Debug (bootstrap): Running command: site ssl (0.694s)
Starting SSL verification.
Debug: Loading account keypair (0.705s)
Debug: Starting check with solver http (0.711s)
Debug: Loading the authorization token for domains harrychapinfoodbank.org … (0.713s)
Debug: Challenge loaded. (0.713s)
Warning: Failed to verify SSL: [malformed] The request message was malformed: Expired authorization (on request “GET https://acme-v02.api.letsencrypt.org/acme/chall-v3/1887857041/0uwrKw”)
Warning: Check logs and retry ee site ssl harrychapinfoodbank.org once the issue is resolved.

Starting SSL cert renewal
Loading current certificate for harrychapinfoodbank.org
Loading current certificate for harrychapinfoodbank.org
Starting SSL verification.
Warning: Challenge Authorization failed. Check logs and check if your domain is pointed correctly to this server.
Re-run ee site ssl www.harrychapinfoodbank.org after fixing the issue.
PHP Fatal error: Uncaught AcmePhp\Core\Exception\Protocol\ChallengeFailedException: Challenge failed (response: {“type”:“http-01”,“status”:“invalid”,“error”:{“type”:“urn:ietf:params:acme:error:dns”,“detail”:“During secondary validation: DNS problem: query timed out looking up A for www.harrychapinfoodbank.org”,“status”:400},“url”:"https://acme-v02.api.letsencrypt.org/acme/chall-v3/6239513210/QJE4zw",“token”:“XpCZAHquSMG4_aorXxTiX8-GQT_bcU_1rHTeR1vlmBo”,“validationRecord”:[{“url”:“http://www.harrychapinfoodbank.org/.well-known/acme-challenge/XpCZAHquSMG4_aorXxTiX8-GQT_bcU_1rHTeR1vlmBo”,“hostname”:“www.harrychapinfoodbank.org”,“port”:“80”,“addressesResolved”:[“165.22.182.8”],“addressUsed”:“165.22.182.8”},{“url”:“http://harrychapinfoodbank.org/.well-known/acme-challenge/XpCZAHquSMG4_aorXxTiX8-GQT_bcU_1rHTeR1vlmBo”,“hostname”:“harrychapinfoodbank.org”,“port”:“80”,“addressesResolved”:[“165.22.182.8”],“addressUsed”:“165.22.182.8”},{“url”:"https://harrychapinfoodbank.org/.well-known/acme-challenge/XpCZAHquSMG4_a in phar:///usr/local/bin/ee/vendor/acmephp/core/AcmeClient.php on line 195
Warning: An Error occurred. Initiating clean-up.
Warning: Exiting gracefully after rolling back. This may take some time.
Success: Rollback complete. Exiting now.

My web server is (include version):
Ubuntu 18.04.4 LTS

The operating system my web server runs on is (include version):
nginx, nginx reverse proxy
ee version 4.1.1

My hosting provider, if applicable, is:

DigitalOcean

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

Notsure - since it’s abstracted in the ee command from easyengine.io

DNSviz
https://dnsviz.net/d/www.harrychapinfoodbank.org/dnssec/
and
https://dnsviz.net/d/harrychapinfoodbank.org/dnssec/

Hi @Mule5

that's a curious error.

That's not relevant because you don't use DNSSEC.

Checking your domain - https://check-your-website.server-daten.de/?q=harrychapinfoodbank.org - there is no name server problem visible. ns63/ns64 from domaincontrol / GoDaddy.

The

error says: The main Letsencrypt servers are able to find the ip address. But the secondary aren't.

But these are not "unknown name servers", GoDaddy should work.

May be a temporary problem, try it one time again.

Thanks for the response.

Same result, same error, same secondary DNS timeout.
This has been happening daily since 7/25, when another domain in this same setup was renewed.


In the same cron/process, 2 sites were queued up for renewal as their SSLs were issued at the same time.
staging.harrychapinfoodbank.org and harrychapinfoodbank.org (with an alternative of www.harrychapinfoodbank.org).
The first to be processed was staging, and it succeeded on 7/25, while the next failed with the timeout on secondary DNS issue. It’s been the same error daily since then, one time daily until yesterday where I’ve manually initiated the process multiple times with debugging.

After a week of trial and error, I’ve reverted the site, disabled the configuration for SSL and restarted the process for a success.

Starting SSL verification.
Debug: Loading account keypair (3.488s)
Debug: Starting check with solver http (3.488s)
Debug: Loading the authorization token for domains harrychapinfoodbank.org, www.harrychapinfoodbank.org … (3.489s)
Debug: Challenge loaded. (3.489s)
Debug: Challenge loaded. (3.796s)
The authorization check was successful!
Debug: Certificate found for harrychapinfoodbank.org, executing renewal (3.86s)
Loading current certificate for harrychapinfoodbank.org
Current certificate will expire in less than 25 days (2020-08-14 00:00:29), renewal is required.
Debug: Loading domain key pair… (3.86s)
Debug: Loading domain distinguished name… (3.861s)
Debug: Loading the order related to the domains harrychapinfoodbank.org, www.harrychapinfoodbank.org. (3.862s)
Renewing certificate for domain harrychapinfoodbank.org.
Certificate received
Certificate stored
Certificate renewed successfully!

Thanks for the eyeballs and allowing me to talk out the solution.

Happy to read that it has worked. :+1:

But: I don't think it's a problem of your system.

  • The error message from Letsencrypt is wrong, so it's not really a dns problem (or)
  • some name servers of Godaddy had blocked some of the secondary validation servers. May be temporary / high number of queries, that looks spammy

You domain uses the same name server.

The GoDaddy name servers have one problem: Sometimes it's terrible to find all ip addresses of these name servers:

A Info:: 27 Root-climbing DNS Queries required to find all IPv4- and IPv6-Addresses of 2 Name Servers.
A Info:: 27 Queries complete, 27 with IPv6, 0 with IPv4.
A Good: All DNS Queries done via IPv6.
Bad (greater 8):: An average of 13.5 queries per domain name server required to find all ip addresses of all name servers.

13,5 is a bad result. Good name server configurations have 1 - 3. My own domain - 15 queries to find 5 name servers = 3 per domain name.

If it requires a lot of time to find the ip addresses of the name servers, that may produce a global "can't find your A-record".

1 Like

Thanks for the reply/response and also your great informational tool.

I agree that the problem most likely wasn’t in house, but external.

It was very odd, since all these commands were executed in order within milliseconds of each other on 7/25. Since the root domain was the same, the look ups should have been the same result on each lookup.

I can’t imagine it working now if the problem was a high number of queries from me (not from world aggregated), since I had submitted the update so many times over the last 3 days, it would surely still be blocked if it were considering just my queries as spam or brute forcing it.

Thanks again. Also happy it’s resolved now.

1 Like

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