Question resolv.conf problems with Ubuntu 22.04 LTS

[D3nnis3n]

resolvectl dns ens6 127.0.0.1

worked.

Unfortunately, after a reboot, this is also overwritten and DNS is back to what 127.0.0.53 finds.
Anyone knows how one can permanently fix the DNS to 127.0.0.1 to allow spam blacklists to work reliably on Ubuntu 24.04?

 

[learning_curve]

Anyone knows how one can permanently fix the DNS to 127.0.0.1 to allow spam blacklists to work reliably on Ubuntu 24.04?

Quick questions (first of all):

a) Are you using Plesk E-Mail Security? (Plesk Extension Free and/or Paid)
b) Are your using netplan on your Ubuntu 24.04 LTS or, did your retain ifupdown form an older Ubuntu release during any Dist-Upgrades?
c) Further to THIS previous post in this thread, are you using systemd-resolve or resolvectl?
d) Can you post the result of: :~# systemd-resolve --status and :~# resolvectl status plus :~# ss -plnt | grep ':53' too, just for clarity?
e) Finally, can you explain in detail, what the actual issue is (for you / your curent config) regarding utilising the results provided by 127.0.0.53 and exactly which file (name / location) contains this command? (see next line). Is it just the functionality of Spam Blacklists as you've posted above? Or is there more?
e.g. ignoring any previous symlinks, is it here: /run/systemd/resolve/resolv.conf ? or here: /run/systemd/resolve/stub-resolv.conf ? and/or other locations too?

IF the overall (Ubuntu) config is correct, then THIS page (which is 24.04 LTS) explains the (intentional) use of a local DNS stub listener with the IP address 127.0.0.53, initially within the 'Description' section and then further on, in detail.

FWIW On Ubuntu 24.04 LTS (see forum sig) Plesk c/w Danami Jugernaut (so no Plesk Firewall and/or Fail2Ban), we have no issues at all, when using:
NO Plesk E-Mail Security / netplan / resolvectl & the symlink: resolv.conf -> ../run/systemd/resolve/stub-resolv.conf which, utilises the IP address 127.0.0.53

 

[D3nnis3n]

Hey,
thanks for answering, @learning_curve, much appreciated.

a) No.
b) We had two dist-upgrades, but are using netplan.
c) We are using resolvectl, systemd-resolve is not found.
d)

root@server-02 ~ # resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens18)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 185.12.64.2
DNS Servers: 185.12.64.1 185.12.64.2 2a01:4ff:ff00::add:1 2a01:4ff:ff00::add:2
DNS Domain: example.com

Link 3 (docker0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (br-2d6bb3e2e3c7)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (br-8f10190baf83)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (veth515e42c)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (vethe97eca8)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

The domain has been anonymized. The DNS servers are the ones provided by the datacenter.
e) Spam blacklists reject our requests due to being from a public resolver, as such anti-spam is not working. This also applies to hosted websites using those blacklists for checking of user registrations. We already have configured SpamAssassin to use 127.0.0.1 seperately, but this doesn't work for the website requests to the blacklists. There is no other issues.

stub-resolve.conf contains 127.0.0.53, resolve.conf contains the data centers DNS servers.
resolvectl dns ens6 127.0.0.1 works to change the nameserver, but does not actually change either of the files and is forgotten.
I did notice it is not forgotten after system reboots, though, but instead after system updates, for some reason.

 

[learning_curve]

a) No

Okay. One less distraction

b) We had two dist-upgrades, but are using netplan

Okay. Current spec then

c) We are using resolvectl, systemd-resolve is not found.

Okay. Again, current spec then

d)

:~# resolvectl status < That's a "busy" output c/w several, separate links, but your note below adds more info, so...
:~# ss -plnt | grep ':53' < Was missing from your reply, but leave that, for the moment

The domain has been anonymized. The DNS servers are the ones provided by the datacenter

Your network config is (obviously) quite different from our own.
Regardless, are those DNS servers initially specified under the [Network] section of a netplan .network file located in here: /run/systemd/network/ ?
If they are, have you then changed them for public revolvers (e.g. Cloudfare IP's) in your .yaml file in here: /etc/netplan/ or no, you've just retained them ?
Assuming yes to both ^^ Then are those same public revolvers (e.g. Cloudfare IP's) also specified in here: /etc/systemd/resolved.conf.d/resolved.conf and in here too: /run/systemd/resolve/resolv.conf ?
If yes to all, plus, all of your other config is setup to suit e.g. /etc/resolv.conf is just a symlink to /run/systemd/resolve/stub-resolv.conf etc then at first glance, there doesn't appear to be an immediately obvious cause for the issue that you've mentioned below (well in these areas anyway...)

e) Spam blacklists reject our requests due to being from a public resolver, as such anti-spam is not working.

Yes. That's often the case now, especially with spamhaus etc but, they do provide a work-around, albeit it takes some effort to configure correctly.
Our anti-spam works fine, but, it is secondary to the detailed anti-spam setup that's provided within Danami Juggernaut (which we use) anyway, so...

This also applies to hosted websites using those blacklists for checking of user registrations.

Yes. See preceding

We already have configured SpamAssassin to use 127.0.0.1 seperately, but this doesn't work for the website requests to the blacklists. There is no other issues.

We haven't (see preceding) so can't add anything to this, other than, the note ^ about the spamhaus work-around which may / may not be useful for you

stub-resolve.conf contains 127.0.0.53,

Yes. As it could / should do really (plus the options data etc)

resolve.conf contains the data centers DNS servers.

This ^ resolve.conf file is this one: /run/systemd/resolve/resolv.conf Is that correct ?
If yes, then why? Unless in your case, your datacenter DNS servers are the exact same servers, as those that you have referred to as public resolvers ?
In our case, we chose NOT to use are datacentre DNS servers other than... in a netplan .network file that's located in here: /run/systemd/network/

resolvectl dns ens6 127.0.0.1 works to change the nameserver, but does not actually change either of the files and is forgotten.

This ^ is where you need input from people using the same / similar config as your own, but we don't, so frustratingly, we can't add any useful comment here

I did notice it is not forgotten after system reboots, though, but instead after system updates, for some reason.

FWIW Yes. Understood. We have examples of this ourselves (including Plesk) but they're not connected with the issue you're having and/or resolve, in any way

 

[D3nnis3n]

:~# resolvectl status < That's a "busy" output c/w several, separate links, but your note below adds more info, so...
:~# ss -plnt | grep ':53' < Was missing from your reply, but leave that, for the moment

Sorry, I forgot that one. Looking at it, it shows all used IP's, which I would have to anonymize. If it's necessary, I'll do that, but given you said "leave that, for the moment" let's see if it works without.

Your network config is (obviously) quite different from our own.
Regardless, are those DNS servers initially specified under the [Network] section of a netplan .network file located in here: /run/systemd/network/ ?
If they are, have you then changed them for public revolvers (e.g. Cloudfare IP's) in your .yaml file in here: /etc/netplan/ or no, you've just retained them ?
Assuming yes to both ^^ Then are those same public revolvers (e.g. Cloudfare IP's) also specified in here: /etc/systemd/resolved.conf.d/resolved.conf and in here too: /run/systemd/resolve/resolv.conf ?
If yes to all, plus, all of your other config is setup to suit e.g. /etc/resolv.conf is just a symlink to /run/systemd/resolve/stub-resolv.conf etc then at first glance, there doesn't appear to be an immediately obvious cause for the issue that you've mentioned below (well in these areas anyway...)

Yes, those datacenter nameservers are specified in /etc/netplan settings (and /run/systemd/network and /run/systemd/resolve/resolved.conf contain the identical ones) - the netplan settings are templated, I use multiple VM's (this is one as well) with the same settings for different purposes. It would be fine to get this to work by changing the original netplan settings, though I'd prefer to not touch them and just have an overwrite that can force the local resolver, as I might want to easily turn that off in the future when the feature is no longer necessary or moved to a different VM. I have tried to do that already, though, and when using 127.0.0.1 in the netplan settings, the VM is no longer able to resolve any domains. /etc/resolv.conf is a symlink to stub-resolv.conf, yes.

Yes. That's often the case now, especially with spamhaus etc but, they do provide a work-around, albeit it takes some effort to configure correctly.
Our anti-spam works fine, but, it is secondary to the detailed anti-spam setup that's provided within Danami Juggernaut (which we use) anyway, so...

For spamhaus we use their free service offered with registration which is fine to use with public resolvers. But other spamlists used do not offer a free contingent with registration or no registration at all and cannot be used, but are vital to our spam blocking.

This ^ resolve.conf file is this one: /run/systemd/resolve/resolv.conf Is that correct ?
If yes, then why? Unless in your case, your datacenter DNS servers are the exact same servers, as those that you have referred to as public resolvers ?
In our case, we chose NOT to use are datacentre DNS servers other than... in a netplan .network file that's located in here: /run/systemd/network/

That is correct. If you ask for the why - I don't know. We only ever adjusted the /etc/netplan settings, everything else is Ubuntu default and wasn't touched. Seemingly the other files get automatically generated based on the netplan file - which the command posted here was supposed to stop, as far as I understood. And yes, the datacenter DNS servers are public resolvers provided by our datacenter provider.

This ^ is where you need input from people using the same / similar config as your own, but we don't, so frustratingly, we can't add any useful comment here

As noted, I would have expected this command to make the necessary changes to use a static local resolver without that reverting, seemingly that is not the case though.

 

[learning_curve]

Sorry, I forgot that one. Looking at it, it shows all used IP's, which I would have to anonymize. If it's necessary, I'll do that, but given you said "leave that, for the moment" let's see if it works without.

Yep. The content might become relevant later on, if the issue is not resolved beforehand

Yes, those datacenter nameservers are specified in /etc/netplan settings (and /run/systemd/network and /run/systemd/resolve/resolved.conf contain the identical ones) - the netplan settings are templated, I use multiple VM's (this is one as well) with the same settings for different purposes.

Okay understood. Yes we use VM's too, but our configs will be different from your own, so we can't add any useful, related comments here, at this stage
However, it would appear that everything you've posted above (brief config details) should allow everything to function, as you intended it too, so...

It would be fine to get this to work by changing the original netplan settings, though I'd prefer to not touch them and just have an overwrite that can force the local resolver, as I might want to easily turn that off in the future when the feature is no longer necessary or moved to a different VM. I have tried to do that already, though, and when using 127.0.0.1 in the netplan settings, the VM is no longer able to resolve any domains.

Did the use of 127.0.0.1 arrive recently via some Plesk changes / updates? ***
Or, was it a change you specifically applied yourselves, maybe... in order to try to achieve local resolver functionality?

/etc/resolv.conf is a symlink to stub-resolv.conf, yes

Yep. Makes sense with the rest of your posted brief config details

For spamhaus we use their free service offered with registration which is fine to use with public resolvers. But other spamlists used do not offer a free contingent with registration or no registration at all and cannot be used, but are vital to our spam blocking.

Yes, spamhaus are far more "assistive" aren't they?
Another config difference (which, is possibly, one of the reasons we don't have the issue you have) is our use of Danami Juggernaut. Presumably, you're using Plesk Firewall (and maybe a.n.other firewall too) plus, Fail2Ban? This is technically not possible, when using Danami Juggernaut. In addition; Although Ubuntu 22.04 / 24.04 etc all use nftables (not iptables) by default, ConfigServer Security & Firewall (csf) currently still uses the iptables interface, so, we also, do need to use; iptables-nft, which provides a bridge to the nftables kernel API and infrastructure, in order to run Danami Juggernaut (which uses csf) correctly. Thinking that you (probably) don't (need to) use iptables-nft anyway? Regardless, the use of iptables-nft will almost certainly not be related to your 'resolve' issue

That is correct. If you ask for the why - I don't know. We only ever adjusted the /etc/netplan settings, everything else is Ubuntu default and wasn't touched. Seemingly the other files get automatically generated based on the netplan file - which the command posted here was supposed to stop, as far as I understood.

Understood. We did a lot of work on our netplan configs (in order for it all to work as we wanted it to, with the default IONOS Cloud servers config). Threfore, this is another config difference, which means, that again, we can't add any useful, related comments here, at this stage, that might relate to your 'resolve' issue

And yes, the datacenter DNS servers are public resolvers provided by our datacenter provider.

Another config difference (see preceding)

As noted, I would have expected this command to make the necessary changes to use a static local resolver without that reverting, seemingly that is not the case though.

The command you're referring to is post #19 in this thread isn't it?
It's a command that we have no need to use, because we don't have the stated 'resolve' issue that needs "correcting"

We're both on the same Ubuntu OS and the same Plesk release on our server(s), but that's where the commonality ends, really...
It would be a lot of work to compare all of the itmes that we've mentioned so far (line by line) but that's possibly the only way...
We've got proof of concept: We're both on the same Ubuntu OS and the same Plesk release, but you have the issue, we don't
"The devil is in the detail" somewhere... within the two different configs!

*** Only raised this, because Plesk is custom-configured to run on different OS's (and variations of them...) but this doesn't always see eye-to-eye with the OS itself... Example: If you run :~# aptitude and wait for the cli / gui to load, how many 'broken' packages are currently being reported on any of your servers?
In our case, it's just 13, but... ALL of them are Plesk Packages and the "suggested" resolution is to remove them all...

Obviously, we've ignored that, as Plesk and Ubuntu 24.04.* LTS ARE compatible, just not in the default Ubuntu / Aptitude preferred way it appears...
However any of these subtle differences, might occasionally cause issues that say Ubuntu 24.04.* LTS with a.n.other platform (e.g. C-Panel) doesn't suffer from
So a long-shot here, is, that the (current) specific config of your own Plesk and Ubuntu 24.04.* LTS setup, triggers one of these subtle differences aka The Issue!