Detail: DNS problem: server failure at resolver looking up A for bawmotorsport.com; DNS problem: server failure at resolver looking up AAAA for bawmotorsport.com
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
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?
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
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.
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: https://acme-v02.api.letsencrypt.org/acme/authz-v3/319170246337
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.
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. https://letsdebug.net/bawmotorsport.com/1814896?debug=y
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.
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 bawmotorsport.com.
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.
