Could not issue an SSL/TLS certificate

My domain is:

I ran this command:

It produced this output:
Invalid response from


Type: urn:ietf:params:acme:error:dns

Status: 400

Detail: DNS problem: server failure at resolver looking up A for; DNS problem: server failure at resolver looking up AAAA for

My web server is (include version): nginx

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

My hosting provider, if applicable, is: PT. Arupa Cloud Nusantara

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

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

Per the error you shared, your hostname is not resolving. Let's Debug is having a similar DNS resolution failure.

You may want to talk with your host or move to a more resilient DNS provider.


You should check your DNS name servers and make sure you are updating the right ones. Your DNS tree is mis-configured

Review all 6 warnings at DNS viz


DNSviz is now all good. DNSSEC activated along with registrar .com DS key as well.

letsencrypt and letsdebug still saying the same thing about A record.

DNS propagation checker ok too:

What else can we check? Why would let's encryp server unable to resolve for A record.

1 Like

There are 2 Nameserver Errors here

And here Hardenize Report:

I suggest resolving them might help.


Ack, fixed the recursive noted in zonemaster. Hardenize does not update.
We can't fix the nameserver on same ip.
However, when we check, the domain resolves, but why does letsencrypt shows it unable to resolve, or does it mean something else behind the error of not resolving A record?

1 Like

Here is what the online tool reports

It is long; I didn't read through all of it.


I also see that single lookups for your A and AAAA records give the correct response on various tools.

Do your DNS servers have any kind of firewall / DoS settings? The Let's Encrypt servers make rapid and numerous queries and can sometimes be blocked by such things.

I see the IP for your DNS server is the same as for your web domain. Is this your long-term plan? Because such a limited presence for DNS servers is not good practice.


It is running on simple web panel plesk, both dns and web are on it.
Works fine with let's encrypt for almost 6 years, somehow broken with that same let's encrypt error for about 20 domains that are on it. Not sure if it is changes or update on plesk side or the let's encrypt (LE) side. Through it all resolving for A record is not a problem which is conflicting with the LE error message

Thanks to all the guide from various site above posts, we are able to fix all, including the recursive as noted on hardenize, so now it is all orange/yellow status.


@arupa, you name servers have poor responsiveness.


Well this really depends on where that dnsspy is located, which I assume in US.
We are in Indonesia, so locally is great.
But we can see the performance here, of course for Asia it varies a lot.
But it is reachable, and it will responds.


The Let's Encrypt server farms are in the US and Europe (today). It uses multipoint validation from various global points which may change in future.

What does your dnsperf test show when using more distant locations?

Are you able to view your DNS logs? You should see many from Let's Encrypt when you request a cert that needs fresh validation. Do you notice odd lags or behavior in the lgos?

A cert request that is a duplicate of a recent one may cache the validation for 30 days so then only the CAA lookup may be done (to ensure you still allow LE). Best to do these tests with --dry-run to avoid that.


Yes; I measure from the USA.

Also note Let's Encrypt uses Multi-Perspective Validation Improves Domain Validation Security - Let's Encrypt


DNSPerf on distant seems to be inline with ping time, so typically USA is about 200-300msec.

I am monitoring the dns error log which on plesk is /var/log/messages showing no errors on those domains we are trying to renew.
The LE requests are logged on /var/log/plesk/panel.log, these shows the same error as letsdebug.
Here is a recent one:

I am completely dumbfounded here looking to find the cause.
It was working fine for many years, only to stop in late January 2024 for all of the domains. I am not sure if Plesk or LE changes something which I do not know that I should comply to.


To me, that seems like the most likely reason for an LE failure [at this time].
Given that:

  • Two nameservers are being used:       nameserver =       nameserver =

But both resolve to the same IP:       internet address =       internet address =

[that means that the (already somewhat heavy) LE DNS requests would be doubled (to that single IP)]

  • No other tools can find a DNS issue [while using single/low DNS query rates]

Oh we did it using a separate IP for NS here. Full green now, I think IPv6 is not necessary as we are not even ready for that one.

Hardenize Result:

Zonemaster ok too:

DNSPerf ok too:

LetsDebug still shows the sames.
Funny enough on DNS inquiry it is able to find the A record shown here in the first red arrow.
But on the acme, it is unable to resolve for A record, second red arrow.

Almost at wits end here...


What systems/programs are used to secure/protect your DNS servers from the Internet?
[anything like: IPS, Firewalls, Fail2Ban, Geo-Location / IP Blocking, etc.]

Also, what does the routing table look like on those DNS servers [and also on the routers immediately in front of the DNS servers]?


We have firewall, nat, and fail2ban.
Monitoring fail2ban blocked IPs, we do think those are from LE. We could flush these and see if it makes any effect.
Firewall external and nat also pass thru all.
We test it from local PCs doing normal nslookup for A, SOA, TXT records.

But all seems to point towards the BIND NS.

1 Like

Definitely worth a try.


We did:

  • turn off firewall on plesk
  • remove all IPs from ban list and turn off fail2ban
  • turn off WAF (I know has nothing to do, as the HTTP portion works on LE)

still comes up with the A record error on LE, like it is unable to resolve

Is there a way to test LE's own DNS lookup, does it try to hit our DNS authorized server? or does it resolve else where, we did check with google dns and it is fine there.

1 Like