Question resolv.conf problems with Ubuntu 22.04 LTS

[Kulturmensch]

Server operating system version

Ubuntu 22.04.2 LTS

Plesk version and microupdate number

Plesk Obsidian v18.0.53_build1800230619.12 os_Ubuntu 22.04

Checking the configuration with Plesk E-Mail security I receive this message:

DNS-Caching ist deaktiviert. Verwenden Sie einen lokalen DNS-Server, um die SPAM-Erkennung über Blockierungslisten zu verbessern (zum Beisiel Plesks DNS-Bind-Server oder systemd-resolved). Anleitung für den DNS-BIND-Server (Englisch)

Is there also an example configuration for systemd-resolved available?

Currently I have bind installed and the files resolv.conf and stub-resolve.conf are managed by systemd-resolved and
/etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf. The file stub-resolv.conf is every 60 second overwritten with the content:

nameserver 127.0.0.53
options edns0 trust-ad
search

To have 127.0.0.1 on top of this what satisfies the needs of Plesk-E-Mail security is lost again every 60 seconds


My last attempt to solve this (https://wiki.ubuntuusers.de/DNS-Konfiguration/) :
1. sudo systemctl stop systemd-resolved
2, sudo systemctl disable systemd-resolved
3. modify /run/systemd/resolve/sub-resolv.conf as

nameserver 127.0.0.1
nameserver 127.0.0.53
options edns0 trust-ad
search

4. restart postfix /dovecot

Now the configuration checked by Plesk EMail-Security does not show the DNS Caching warning, the resolver tests in the bash work fine and eventually the files resolv.conf and stub-resolv.conf do not get overwritten again and again.

But now the following proglem comes up - I cannot receive E-Mails any longer because the following errors:

network unreachable resolving 'rub.de.dbl.spamhaus.org/A/IN': 2001:1470:8000:c::39#53 (and all other spam-lists)

and a test E-Mail from outside is not delivered beacause:

Client host [194.25.134.20] blocked using
zen.spamhaus.org; Error: open resolver;
DNSBL Error Code - Open/public resolver - The Spamhaus Project (in reply to RCPT TO
command)

(For the last one my first idea was that it could belong to the nameserver by cloudflare and I replaced 1.1.1.1 with 8.8.8.8 (google) but the same problems happend again - incoming E-Mails got blocked

So, my question is does anyone has a recipe how to configure the systemd-resolver to work with Plesk-E-Mail security? I.e. to have permanent the entry 127.0.0.1 on top of the resolv.conf file?

The configuration /etc/systemd/resolved.conf is proably the key to the solution:

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it under the
# terms of the GNU Lesser General Public License as published by the Free
# Software Foundation; either version 2.1 of the License, or (at your option)
# any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
DNS=8.8.8.8
FallbackDNS=8.8.4.4
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

Is there a Plesk example how to configure it in an optimal manner to solve the problems mentioned above?

 

[tramvainqueur]

So lange keine Lösung gefunden laut Plesk Community Anfrage?

Na, ich will nicht so fies sein ... ich erkläre meinen gefundenen Lösungsweg am Ende ausführlich, falls diese Ionos-Hilfeseite doch durch irgendein Update oder Change verschwindet.

Mich wunderte die Fehlermeldung auch, dass sie immer wieder nach Neustart erschien. Allerdings wusste ich aus Erfahrung, dass sich in Linux laut Netzwerkeinstellungen im System einiges geändert hatte. Evtl. ein anderes Problem war, Plesk setzt die Einstellung vom Nameserver immer wieder nach dem Neustart zurück, was mich allerdings seh gewundert hätte, da Plesk selbst sich wegen dieser Uribl DNSBL beschwerte, dass angeblich kein lokaler Cachingnameserver vorhanden sei. Eine Suche ergab in Plesk wie vermutet nichts. Dann verfolgte ich meine andere Idee, dass man in Ubuntu die Nameserver nun anders konfigurieren muss. Also suchte ich mit Google und es fand sogar von Ionos selbst eine Seite, die eine Möglichkeit für eine permanente Nameserverkonfiguration ermöglicht. Die Seite heißt Ubuntu DNS-Server ändern - so geht's!. Laut cat im Terminal steht in resolv.conf nun der gewünschte lokale Nameserver. Und Plesk selbst beschwert sich nicht mehr.

Da diese Seite auf Deutsch ist und sie offenbar Deutscher sind oder ihren Server auf Deutsch benutzen und daher ganz sicher Deutsch können, nehme ich an, dass ihnen die Anleitung von Ionos auch hilft den Nameserver endlich permannt einstellen zu können. Viel Spaß!


ausführliche Anleitung mit fast nur relevantem Inhalt:
Damit es durch Updates nicht verloren geht, hier noch einmal der relevante Inhalt:

1) installiere, falls noch nicht installiert (war bei meinem Vserver nicht nötig):

sudo apt update
sudo apt upgrade
sudo apt install resolvconf

2) überprüfe ob aktiviert:

sudo systemctl status resolvconf.service

2a) falls noch nicht aktiviert (war bei meinem Vserver nicht nötig):

sudo systemctl
sudo systemctl start resolvconf.service
sudo systemctl enable resolvconf.service
sudo systemctl status resolvconf.service

3) ändere head (nicht irritieren, dass gewarnt wird, dies wird überschrieben, dann das wird für das Update von resolv.con benötigt)

sudo nano /etc/resolvconf/resolv.conf.d/head

und den Nameservereintrag 'nameserver 127.0.0.1' hinzufügen.

4) resolv.conf aktualisieren durch folgende Befehle:
{CODE=bash}
sudo resolvconf --enable-updates
sudo resolvconf -u{/CODE}

5) überprüfe in Ubuntu 18.04 & 20.04 mit

systemd-resolve --status

oder in Ubuntu 22.04 mit

resolvectl status

6) überprüfe mit

host -tTXT 2.0.0.127.multi.uribl.com

. Wenn das Resultat

2.0.0.127.multi.uribl.com descriptive text "permanent testpoint"

ist, funktioniert die DNSBL-Abfrage bei Uribl in Zukunft auch nach Neustarts.

 

[Peter Debik]

Postings in another language but English are normally quite useless in an international forum.

 

[tramvainqueur]

Postings in another language but English are normally quite useless in an international forum.

User @Kulturmensch is german and the helping site of Ionos where his virtual server or physical server is managed by Plesk is a german site. It was late, so I did not want to translate the whole site. Perhaps I or another one posts a translation of this. Lastly this is a fault of Plesk that it advices setting a permanent nameserver in a form that after a restart of the server the newly set nameserver is lost.

So moreover you should thank me I found a solution for a problem which seem to have many users since 2022 with Ubuntu 22.04 although Plesk officially recommends using Ubuntu 22.04. So normally it is your task or the task of another Plesk employee to translate my found solution of the german Ionos-site and update Plesk when it warns that it does not finde a local nameserver.

So please Mr. Debik or other Plesk employee reading this, be a god person and advice at least another employee who is in the developing process of Plesk to update the advice of Plesk if no local nameserver is found and modify Plesk in that way that it can automatically configure a local caching nameserver in Ubuntu 22.04 and forwarding. Thank you in forward!

 

[Kaspar]

[..] I found a solution for a problem which seem to have many users since 2022 with Ubuntu 22.04 although Plesk officially recommends using Ubuntu 22.04.

Which is exactly why posting in English is beneficial, that way much more forum members can benefit from your solution.

 

[tramvainqueur]

@AYamshanov : Think before posting a like. The accusation is more or less destructive as no rule says postings have to be always English. As you seem to be Bulgarian (said from profile), it seems you can no German. Else you would have understood why my previous post was only in german as I wanted to sleep at 3am in Germany and therefore I did not have time to translate the german Ionos site. Plesk should be thankful that I found a solution for a problem which many have since about 3 years.

 

[tramvainqueur]

@Kaspar : Yes, this is right, but it was about 3am in germany. And now I have to do more important work. That is why I can not translate the erman site immediately.

Until (undefined time span) later. If someone can translate the german Ionos-site or my last and with almost only relevant informations, this would be great for the community.

 

[Kaspar]

@Kaspar : Yes, this is right, but it was about 3am in germany. And now I have to do more important work. That is why I can not translate the erman site immediately.

Until (undefined time span) later. If someone can translate the german Ionos-site or my last and with almost only relevant informations, this would be great for the community.

Nobody forced you to post at 3 am. That was your choice. You could've gone to bed and posted the next day in English when rested. Just saying ...

Anyway, fortunately, Ionos was kind enough to also publish the same article in English: How to change DNS servers on Ubuntu 18.04, 20.04 and 22.04

 

[Peter Debik]

The accusation is more or less destructive as no rule says postings have to be always English.

You are right. I should have just ignored the post or removed it and went on. Or I should have translated it as a courtesy translation as done before in some other posts. With my post I meant to bring to your attention that it is also a form of politeness to enable all users on a forum to understand what others are talking about. You would not want to speak a language only your partner and you understand while other people are in the room who don't speak that language.

As we have a large Germany community, we've before seen that there is a tendency that they discuss issues in their own language, e.g. recently on the Facebook group. This excludes all others however, so it is not so welcome for other users as it excludes them from the knowledge and the conversation in general.

 

[learning_curve]

Caveats:
We've never had this issue that's described in Post #1 despite us using IONOS Cloud Servers that are currently running on Ubuntu 22.04 LTS (and that were running on Ubuntu 20.04 LTS / 18.04 LTS previously).
We've never used the Plesk-E-Mail Security Extension, so that's a major difference. We use other other methods / apps to cover the same.
The translation 'issue' in this thread, is what it is. Not getting involved with that one...

Therefore, this post, is merely to identify some other information, that might be relevant and therefore useful to any future readers of this thread.

We've never need to install resolvconf and then use the resolvconf.service (as has been posted within this thread) whilst using Ubuntu 22.04, in order to change DNS Servers. That's because, with many of the Ubuntu 22.04 releases (including the ones we use, but you can easily check your own @Kulturmensch to be sure) systemd-resolve was renamed to resolvectl Yes it's similar, but there's use of different syntex etc, to gain results. So, focusing just on resolvectl then;

resolvectl --help

Will produce all the help that's needed:

Expand/Collapse Block: resolvectl -- help (detailed output)

resolvectl [OPTIONS...] COMMAND ...

Send control commands to the network name resolution manager, or
resolve domain names, IPv4 and IPv6 addresses, DNS records, and services.

Commands:
query HOSTNAME|ADDRESS... Resolve domain names, IPv4 and IPv6 addresses
service [[NAME] TYPE] DOMAIN Resolve service (SRV)
openpgp EMAIL@DOMAIN... Query OpenPGP public key
tlsa DOMAIN[ORT]... Query TLS public key
status [LINK...] Show link and server status
statistics Show resolver statistics
reset-statistics Reset resolver statistics
flush-caches Flush all local DNS caches
reset-server-features Forget learnt DNS server feature levels
dns [LINK [SERVER...]] Get/set per-interface DNS server address
domain [LINK [DOMAIN...]] Get/set per-interface search domain
default-route [LINK [BOOL]] Get/set per-interface default route flag
llmnr [LINK [MODE]] Get/set per-interface LLMNR mode
mdns [LINK [MODE]] Get/set per-interface MulticastDNS mode
dnsovertls [LINK [MODE]] Get/set per-interface DNS-over-TLS mode
dnssec [LINK [MODE]] Get/set per-interface DNSSEC mode
nta [LINK [DOMAIN...]] Get/set per-interface DNSSEC NTA
revert LINK Revert per-interface configuration
log-level [LEVEL] Get/set logging threshold for systemd-resolved

Options:
-h --help Show this help
--version Show package version
--no-pager Do not pipe output into a pager
-4 Resolve IPv4 addresses
-6 Resolve IPv6 addresses
-i --interface=INTERFACE Look on interface
-p --protocol=PROTO|help Look via protocol
-t --type=TYPE|help Query RR with DNS type
-c --class=CLASS|help Query RR with DNS class
--service-address=BOOL Resolve address for services (default: yes)
--service-txt=BOOL Resolve TXT records for services (default: yes)
--cname=BOOL Follow CNAME redirects (default: yes)
--validate=BOOL Allow DNSSEC validation (default: yes)
--synthesize=BOOL Allow synthetic response (default: yes)
--cache=BOOL Allow response from cache (default: yes)
--zone=BOOL Allow response from locally registered mDNS/LLMNR
records (default: yes)
--trust-anchor=BOOL Allow response from local trust anchor (default: yes)
--network=BOOL Allow response from network (default: yes)
--search=BOOL Use search domains for single-label names (default: yes)
--raw[=payload|packet] Dump the answer as binary data
--legend=BOOL Print headers and additional info (default: yes)

See the resolvectl(1) man page for details.

We've never had any problems applying our desired configs, only using resolvectl and

resolvectl status

as @tramvainqueur has already posted, gives all of the confirmatory information that's needed after making those changes. HERE is the 22.04 resolvectl(1) man that's referred to at the end of the above SPOILER (This page actually covers lots of Ubuntu releases, even the forthcoming 24.04)

The IONOS link that @tramvainqueur has posted, can be useful (as one part of its content does appears to have been, in this case). However, IONOS sometimes, still provide their Server Packages c/w Pre-Installed Ubuntu OS that use ifupdown (or sometimes, even systemd-networkd) not netplan, so that, plus the specific type of server and it's config that they provide... might add variables that aren't covered on that specific IONOS page.

 

[tramvainqueur]

Caveats:
We've never had this issue that's described in Post #1 despite us using IONOS Cloud Servers that are currently running on Ubuntu 22.04 LTS (and that were running on Ubuntu 20.04 LTS / 18.04 LTS previously).
We've never used the Plesk-E-Mail Security Extension, so that's a major difference. We use other other methods / apps to cover the same.
The translation 'issue' in this thread, is what it is. Not getting involved with that one...

Therefore, this post, is merely to identify some other information, that might be relevant and therefore useful to any future readers of this thread.

We've never need to install resolvconf and then use the resolvconf.service (as has been posted within this thread) whilst using Ubuntu 22.04, in order to change DNS Servers. That's because, with many of the Ubuntu 22.04 releases (including the ones we use, but you can easily check your own @Kulturmensch to be sure) systemd-resolve was renamed to resolvectl Yes it's similar, but there's use of different syntex etc, to gain results. So, focusing just on resolvectl then;

resolvectl --help

Will produce all the help that's needed:

Expand/Collapse Block: resolvectl -- help (detailed output)

resolvectl [OPTIONS...] COMMAND ...

Send control commands to the network name resolution manager, or
resolve domain names, IPv4 and IPv6 addresses, DNS records, and services.

Commands:
query HOSTNAME|ADDRESS... Resolve domain names, IPv4 and IPv6 addresses
service [[NAME] TYPE] DOMAIN Resolve service (SRV)
openpgp EMAIL@DOMAIN... Query OpenPGP public key
tlsa DOMAIN[ORT]... Query TLS public key
status [LINK...] Show link and server status
statistics Show resolver statistics
reset-statistics Reset resolver statistics
flush-caches Flush all local DNS caches
reset-server-features Forget learnt DNS server feature levels
dns [LINK [SERVER...]] Get/set per-interface DNS server address
domain [LINK [DOMAIN...]] Get/set per-interface search domain
default-route [LINK [BOOL]] Get/set per-interface default route flag
llmnr [LINK [MODE]] Get/set per-interface LLMNR mode
mdns [LINK [MODE]] Get/set per-interface MulticastDNS mode
dnsovertls [LINK [MODE]] Get/set per-interface DNS-over-TLS mode
dnssec [LINK [MODE]] Get/set per-interface DNSSEC mode
nta [LINK [DOMAIN...]] Get/set per-interface DNSSEC NTA
revert LINK Revert per-interface configuration
log-level [LEVEL] Get/set logging threshold for systemd-resolved

Options:
-h --help Show this help
--version Show package version
--no-pager Do not pipe output into a pager
-4 Resolve IPv4 addresses
-6 Resolve IPv6 addresses
-i --interface=INTERFACE Look on interface
-p --protocol=PROTO|help Look via protocol
-t --type=TYPE|help Query RR with DNS type
-c --class=CLASS|help Query RR with DNS class
--service-address=BOOL Resolve address for services (default: yes)
--service-txt=BOOL Resolve TXT records for services (default: yes)
--cname=BOOL Follow CNAME redirects (default: yes)
--validate=BOOL Allow DNSSEC validation (default: yes)
--synthesize=BOOL Allow synthetic response (default: yes)
--cache=BOOL Allow response from cache (default: yes)
--zone=BOOL Allow response from locally registered mDNS/LLMNR
records (default: yes)
--trust-anchor=BOOL Allow response from local trust anchor (default: yes)
--network=BOOL Allow response from network (default: yes)
--search=BOOL Use search domains for single-label names (default: yes)
--raw[=payload|packet] Dump the answer as binary data
--legend=BOOL Print headers and additional info (default: yes)

See the resolvectl(1) man page for details.

We've never had any problems applying our desired configs, only using resolvectl and

resolvectl status

as @tramvainqueur has already posted, gives all of the confirmatory information that's needed after making those changes. HERE is the 22.04 resolvectl(1) man that's referred to at the end of the above SPOILER (This page actually covers lots of Ubuntu releases, even the forthcoming 24.04)

The IONOS link that @tramvainqueur has posted, can be useful (as one part of its content does appears to have been, in this case). However, IONOS sometimes, still provide their Server Packages c/w Pre-Installed Ubuntu OS that use ifupdown (or sometimes, even systemd-networkd) not netplan, so that, plus the specific type of server and it's config that they provide... might add variables that aren't covered on that specific IONOS page.

Thank you!

IMHO your solution seems to be much better than the possible solution I found. I am no sysadmin (only computer scientist) but I like it that one has not to install new systems as this can be risky that after this change the server has no network access anymore. And as you mentioned, Ionos may change things and this can make problems in future (I hope this does not happen with my little server). Thank you again!

 

[tramvainqueur]

You are right. I should have just ignored the post or removed it and went on. Or I should have translated it as a courtesy translation as done before in some other posts. With my post I meant to bring to your attention that it is also a form of politeness to enable all users on a forum to understand what others are talking about. You would not want to speak a language only your partner and you understand while other people are in the room who don't speak that language.

As we have a large Germany community, we've before seen that there is a tendency that they discuss issues in their own language, e.g. recently on the Facebook group. This excludes all others however, so it is not so welcome for other users as it excludes them from the knowledge and the conversation in general.

Please be not that defeatist. If you would have removed and went on, this surely would have happened to more users. And about 50% of these users would have complained about this at the company. On many community sites posts are not deleted but archived, so in a research of the company they can easily find out that they rightly complained. Then the consequences for you would be not nice. So I would suggest not to do this on similar postings.

Ignoring would be a bit cowardly. I think it is better to be courageous.

But if you would have proposed me that I shall prefer writing in English for the community, I surely would not have reacted that harsh and I would have tried to find time translating this what thankfully @Kaspar found that this is not needed (nevertheless, solution of @learning_curve seems to be better imho). It was late, like today I did not sleep much and because of a heavy accident my skin seems to be a bit tender. So sorry if my reaction was to harsh. So please be more insightful that other do not be always in good condition. And I did not want to exclude anybody, just write it quick and I was a bit annoyed that this problems seemed to result from Plesk and their tip was bad.

Last but nor least: I hope you forward the proposal as solution to an developer of Plesk, if you are not this yourself. I think a soluion like them from @learning_curve can be easily integrated in future Plesks. Thank you in forward!

 

[fanke]

The default IONOS Plesk installation uses DHCP, at least with Debian installations. The DHCP-client requests, on default, DNS-servers from the DHCP-server, which are IONOS-servers.

After editing the /etc/dhcp/dhclient.conf
and removing the entry "domain-name-servers"

I was able to edit the /etc/resolv.conf without getting it changed by other processes in the future.

 

[learning_curve]

The default IONOS Plesk installation uses DHCP, at least with Debian installations. The DHCP-client requests, on default, DNS-servers from the DHCP-server, which are IONOS-servers. After editing the /etc/dhcp/dhclient.conf and removing the entry "domain-name-servers", I was able to edit the /etc/resolv.conf without getting it changed by other processes in the future.

Good to know, although you've not actually said what the issue was, the issue that led you to find the need to do this?
If it's exactly the same as the OP's, then just tell us. Or, if this what you're suggesting is a fix for the OP's issue, then again, just tell us that please.

FWIW It would also be a great help if you could add a forum signature, because other than you mentioning Debian in your post, none of us have any idea what else is involved. It would perhaps also be good in this case, to identify exactly, which IONOS server(s) you're using too (as there many different types).