Resolved Error code: (26) DNS lookup failure, failed SPF check for some incoming mails

[powermove]

Dear all,

I'm running a new Linux server with Plesk installed. Here some data:

Linux: Ubuntu 20.04.3 LTS
Plesk: Plesk Obsidian Version 18.0.39
Extension: Plesk Email Security
Postfix
Note: I use a standard installation of Ubuntu and Plesk through the hoster.

So I found the following log in my maillog for incoming test mails for a testsetup from a web.de e-mail address. Since I'm still testing the server I currently see this error only for mails from web.de. A mail coming e.g. from googlemail.com does not produce this error, as well as a mail coming from another of my Plesk servers. In those examples the SPF check works fine. Nevertheless this error does not appear in the logfile of my other Plesk server receiving a mail from web.de.

2021-10-25 10:41:20	postfix/qmgr[35602]	A3E95140013: removed
2021-10-25 10:41:20	postfix/smtp[93336]	A3E95140013: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.6, delays=0.6/0.01/0.01/1, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as C28F9140058)
2021-10-25 10:41:20	amavis[93276]	(93276-01) Passed CLEAN {RelayedInbound}, [212.227.15.14]:40779 [186.84.90.87] <[email protected]> -> <[email protected]>, Queue-ID: A3E95140013, Message-ID: <[email protected]>, mail_id: 2cr9JhsKHPL5, Hits: -0.175, size: 278044, queued_as: C28F9140058, dkim_sd=dbaedf251592:web.de, 1022 ms
2021-10-25 10:41:20	postfix/qmgr[35602]	C28F9140058: from=<[email protected]>, size=278924, nrcpt=1 (queue active)
2021-10-25 10:41:20	psa-pc-remote[51435]	C28F9140058: check-quota: stderr: SKIP
2021-10-25 10:41:20	psa-pc-remote[51435]	C28F9140058: spf: stderr: PASS
2021-10-25 10:41:20	psa-pc-remote[51435]	C28F9140058: py-limit-out: stderr: SKIP
2021-10-25 10:41:20	psa-pc-remote[51435]	C28F9140058: py-limit-out: stderr: INFO:__main__:No SMTP AUTH and not running in sendmail context (incoming or unrestricted outgoing mail). SKIP message.
2021-10-25 10:41:19	postfix/cleanup[93329]	C28F9140058: message-id=<[email protected]>
2021-10-25 10:41:19	psa-pc-remote[51435]	C28F9140058: from=<[email protected]> to=<[email protected]>
2021-10-25 10:41:19	postfix/smtpd[93339]	C28F9140058: client=localhost[127.0.0.1], orig_queue_id=A3E95140013, orig_client=mout.web.de[212.227.15.14]
2021-10-25 10:41:19	postfix/smtpd[93339]	connect from localhost[127.0.0.1]
2021-10-25 10:41:19	postfix/smtpd[93323]	disconnect from mout.web.de[212.227.15.14] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
2021-10-25 10:41:19	postfix/qmgr[35602]	A3E95140013: from=<[email protected]>, size=277841, nrcpt=1 (queue active)
2021-10-25 10:41:19	psa-pc-remote[51435]	A3E95140013: check-quota: stderr: SKIP
2021-10-25 10:41:19	psa-pc-remote[51435]	A3E95140013: spf: stderr: PASS
2021-10-25 10:41:19	spf[93334]	A3E95140013: Failed to query MAIL-FROM: Temporary DNS failure for 'web.de'.
2021-10-25 10:41:19	spf[93334]	A3E95140013: Error code: (26) DNS lookup failure
2021-10-25 10:41:18	psa-pc-remote[51435]	A3E95140013: py-limit-out: stderr: SKIP
2021-10-25 10:41:18	psa-pc-remote[51435]	A3E95140013: py-limit-out: stderr: INFO:__main__:No SMTP AUTH and not running in sendmail context (incoming or unrestricted outgoing mail). SKIP message.
2021-10-25 10:41:18	postfix/cleanup[93329]	A3E95140013: message-id=<[email protected]>
2021-10-25 10:41:18	psa-pc-remote[51435]	A3E95140013: from=<[email protected]> to=<[email protected]>
2021-10-25 10:41:18	postfix/smtpd[93323]	A3E95140013: client=mout.web.de[212.227.15.14]
2021-10-25 10:41:18	postfix/smtpd[93323]	TLS SNI mail.gokiwigo.de from mout.web.de[212.227.15.14] not matched, using default chain
2021-10-25 10:41:18	postfix/smtpd[93323]	connect from mout.web.de[212.227.15.14]

I also checked this thread: Resolved - Error code: (26) DNS lookup failure but I'm not sure if this applies to me, since some other DNS lookups for SPF just work fine. Neverthless I post the content of the following file, which nevertheless should not be edited directly.


Also here the status of the current systemd-resolve:


What else can I check? I have no idea how to solve this problem - what should be done to solve this error? Thanks in advance for your help.

 

[Nik G]

hello @powermove
what is the output of the command "nslookup -type=TXT web.de" at your server ?

provided error above looks like a malfunctioning of resolve server.
you can try to reconfigure your server to using some public DNS server

 

[powermove]

Hi @Nik G

thanks a lot for your fast answer. Here is the output.



Indeed it does not resolve this command. For googlemail.com it does work.


Well I know public DNS servers (e.g. Google, etc.) and I also saw the suggestion of changing the resolve.conf. Nevertheless the file says, that it should not be edited. To be honest I have no experience for this kind of server reconfiguration.

Can anybody guide me to a working tutorial, how to change this part for Ubuntu 20.04 + Plesk?

 

[powermove]

Just to add. I allready tried to alter the config here:

/etc/systemd/resolved.conf - I changed the primary DNS to 8.8.8.8. I restarted afterwards systemctl restart systemd-resolved.service.

I also get now the following output for systemd-resolve:

 

[powermove]

Afterwards I tried nslookup -type=TXT web.de again and it still shows the same response like posted above.

Obviously I'm missing knowlege here. 127.0.0.53 seems as IP in the symlink etc/resolve.conf not wrong since it is just passing some DNS information of the server itself (having looked here: DNS set to systemd's 127.0.0.53 - how to change permanently?).

Thus hopefully somebody can explain me in easy way, how to solve this issue.

 

[Nik G]

@powermove ,
I guess you also need to execute "systemd-resolve --flush-caches" or simply reboot the server to fully apply all changes.

actually, it is probably not a best solution but just a temporary workaround because using public DNS server you will not be able to resolve internal resources.

from my point of view it would be better to ask your server provider why their DNS server can't resolve records for web.de.

 

[learning_curve]

FWIW @powermove When using a similar setup (see forum signature) but on cloud servers being hosted by IONOS & not your ISP (is it Dogado maybe?) we did have some similar, initial DNS resolution issues, when we first moved over from Ubuntu 18.04 LTS & on to Ubuntu 20.04 LTS. The final adjusted version of /etc/systemd/resolved.conf can be a lot more detailed, which might assist you, IF, the final comment by @Nik G above, doesn't fix the issue for you. With IONOS, excluding their own DNS servers and replacing then with public DNS servers caused issues after a set period of uptime. The answer in that case, was using public DNS servers, only but as Fallback DNS servers (see attached sanitised image which is taken from the top of the output of systemd-resolve --status - which you've already run yourself) That edit took care of the odd rare occasion, when there was a glitch with the IONOS DNS servers themselves. The official Ubuntu starting page on the very subject is HERE and again just FWIW next time you have the issue, you can start to troubleshoot via CLI with this:

journalctl -u systemd-resolved -f

In the output from that ^ you can see what systemd-resolved is actually doing (or NOT doing) for you and then go from there.
We can resolve ALL of the DNS/IPs that you've posted, either locally of from servers so, it can only be server misconfig that's preventing you from doing so.

 

[powermove]

Hi @Nik G and @learning_curve,

first thanks to both of you for sharing your knowledge here. This is very helpful. Many thanks.

@learning_curve: It is Alfahosting which seems to use Dogado. Thus yes.

It was not necessary in my case to flush the cache. It works after I changed the /etc/systemd/resolved.conf file almost like suggest.

I added Fallback DNS as well as DNSSEC setting like suggest by you @learning_curve. Nevertheless with the DNSoverTLS setting nothing was longer resolved:



I turned of the DNSoverTLS setting and it is working now .


I will have an eye on the maillogs but it seems to be solved for me. If not I will get back.

Thank you guys.