SERVFAIL looking up A


Another of our customers has several Plesk servers with a horrible DNS setup, they created 3 NS all pointing to the same host. Due to the volumen of domains involved, it's not feasible changing that in the short/mid term.

Thing is that...

# plesk bin extension --exec letsencrypt cli.php -d -m -----@----.---
[2022-01-17 13:34:05.000] ERR [extension/letsencrypt] The execution of cli.php has failed with the following message:
[2022-01-17 13:34:04.982] ERR [extension/letsencrypt] Domain validation failed for Invalid response from
Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: DNS problem: SERVFAIL looking up A for - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for - the domain's nameservers may be malfunctioning

The domain has 3 different NS all pointing to the same IP address, which resolves correctly the A entry for it. I frankly have no idea what's wrong.

So where is this error coming from?


3 Likes      nameserver =      nameserver =      nameserver =

[false sense of redundancy]

Let's Debug (
DNS Spy report for

1 Like

Funny, because the test sites I checked, were all fine!


DNS Spy only gives some recommendations but not any substantial evidence of the SERVFAIL or anything else fatal. And Let's Debug unfortunately only shows the end result and not what might have caused it..

Trying Let's Debug again shows no issues at all: Let's Debug

So the issue is probably intermitting..

Há, yes, after trying 10 times, I got Unboundtest to fail:

1 Like

That's called: Perspective / Vantage Point
Being the entire DNS system one single IP, I find that quite easy for anything from Fail2Ban or GeoLocation blocking to easily wreak havoc upon it's usefulness.

Then you missed the single IP.

1 Like

That's not the issue in a strict sense. Yes, it might be the problem leading to the actual error, but by itself it's not producing the error. Without other factors, it might be just fine all the time.

Note that Unboundtest is fine 9 out of 10 times (more or less). So something is acting up occasionally, but not every time.

It probably has a DNSSEC origin. If you compare the working and non-working unboundtests above, you'll see the working test has some DNSSEC stuff at the bottom, verifying some non-existing DNSSEC records. (From the "prime trust anchor" part onwards.) That DNSSEC stuff is missing on the erroneous test. It just quits after "query response was ANSWER".

1 Like

Yeah I know, but it's some customer stubbornness in action sadly.

1 Like

The fact that they want, in a (I know) stupid way, to maintain that setup (probably because there are lots of domains involved and noone wants to mess with changing the nameservers among quite many registrars, also who-whas-the-admin-account for here-or-there?, etc), doesn't mean that it can't be valid (yes, it's not redundant, it's silly doing it that way in today's Internet, but it's still 100% technically valid), and our work there is just proposing improvements (sometimes not accepted, like this case), maintenance and support. They have many other domains in that same server, with the same DNS setup (three nameservers all pointing to the host itself), and all of them can get certificates from Letsencrypt without issues.

It's not, also, any fail2ban (I hate it) issue, because since the beginning I made the tests adding a generic ACCEPT rule on top of the INPUT/OUTPUT chains.

It's weird, I know :expressionless:

The DNSSEC extension is not even installed in that Plesk server, and the zone file for the domain is pretty simple:

# cat 
; *** This file is automatically generated by Plesk ***
$TTL    60

@       IN      SOA ---.---.---. (
                        2022011702      ; Serial
                        180     ; Refresh
                        60      ; Retry
                        420     ; Expire
                        180 )   ; Minimum              IN NS              IN NS              IN NS                 IN A              IN A              IN A          IN CNAME          IN CNAME              IN MX  10              IN TXT  "v=spf1 +a +mx -all"               IN TXT  "v=DMARC1; p=none"

No matter how many times, either manually or scripting some simple loop, I query the nameserver over and over, I always get a valid response for the A record.

1 Like

There are already three names.
The "change" would be simply to point those names to multiple IPs.
[no changes at any registrars required]

From that one single source IP.

Unfortunately, other IPs have other views/results.

1 Like

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