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 3videnze.education -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 3videnze.education: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/69185151230.
Details:
Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: DNS problem: SERVFAIL looking up A for 3videnze.education - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for 3videnze.education - the domain's nameservers may be malfunctioning
The domain 3videnze.education 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.
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..
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.
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".
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
The DNSSEC extension is not even installed in that Plesk server, and the zone file for the domain is pretty simple:
# cat 3videnze.education
; *** This file is automatically generated by Plesk ***
$TTL 60
@ IN SOA ns1.pulso.com. ---.---.---. (
2022011702 ; Serial
180 ; Refresh
60 ; Retry
420 ; Expire
180 ) ; Minimum
3videnze.education. IN NS ns1.pulso.com.
3videnze.education. IN NS ns2.pulso.com.
3videnze.education. IN NS mercurio.aduxia.net.
mail.3videnze.education. IN A 54.36.248.100
3videnze.education. IN A 54.36.248.100
webmail.3videnze.education. IN A 54.36.248.100
www.3videnze.education. IN CNAME 3videnze.education.
ftp.3videnze.education. IN CNAME 3videnze.education.
3videnze.education. IN MX 10 mail.3videnze.education.
3videnze.education. IN TXT "v=spf1 +a +mx +a:mercurio.aduxia.net -all"
_dmarc.3videnze.education. 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.
