How to disable systemd-resolved in Ubuntu?

Question

How can I disable systemd-resolved in Ubuntu 17.04?

Disabling it with systemctl disable didn't work, the service seems to be restarted (by Networkmanager?)

systemd-resolved isn't just big, it also breaks the way dns resolution works by not always attempting to resolve in the order dns servers are specified in the client config. When a server doesn't resolve a domain, the next in the list is moved to the top (Poettering calls that 'memory'). See this thread for the details. — LifeBoy, Jun 26 '17 at 06:57
@LifeBoy I noticed systemd-resolved Cache config now defaults to "no"... I have the opposite problem... Some websites have so many nested CDN's they cause 8.8.8.8 to throttle us... hence we need caching and a local dns server. Manually configuring unbound for the first time, DNSoverTLS should be a nice bonus. Moral of the story, don't upgrade and expect everything to be the same, I'm starting fresh and loving it. — Ray Foss, Feb 06 '21 at 18:15
It occurs to me that the _gateway name is provided by systemd-resolved... My entire networking stack relies on that was braking my system every time I tried to host a full featured DNS. :facepalm: — Ray Foss, Feb 06 '21 at 18:23
@Spongman Could you please provide a reference for systemd-resolved overriding or bypassing iptables rules? I can't seem to find anything on Google or DuckDuckGo that suggests this is true — Harold Fischer, Mar 19 '21 at 19:48
@HaroldFischer i don't have a reference. try it yourself: add some iptables rules for redirecting DNS traffic (in my case i was doing this on a per-user basis), then enable systemd-resolved and see how it completely ignores the iptables rules. at least, it did ~Oct/2018. haven't tried it since then. — Spongman, Mar 22 '21 at 18:49
@Spongman Thanks for reaching out. I wasn't trying to be rude, it's just nice to have a reference. As far as you're aware, is it only iptables DNS rules that get overridden by systemd-resovled? Also a quick example to make sure I understand you: let's say I put an iptable rule that blocks access to 8.8.8.8; systemd-resovled is set to use Google DNS and happily ignores my rule denying access to 8.8.8.8- is this the kind of behavior you mean? — Harold Fischer, Mar 28 '21 at 01:44
@HaroldFischer no offense taken. i had a similar situation, i was using iptables to conditionally redirect outgoing dns traffic to different servers based on the local group-id. i don't remember the exact iptables incantations (i think i was using shorewall to do it). anyway... i updated my OS and systemd-resolved got installed, and the iptables rules stopped working - all DNS traffic was sent directly to the configured server bypassing the iptables rules. — Spongman, Mar 30 '21 at 23:15
@Spongman With that iptables setup it likely "bypass" the rules since the user sends queries to systemd-resolved and that sends the actual requests out with it's UID and GID (which is the same for all users) — Gert van den Berg, Nov 03 '21 at 15:06
@GertvandenBerg i do seem to remember trying to remove the iptables user filter and the DNS traffic still wasn't getting routed through iptables. disabled systemd-resolved and everything started working fine. i believe i even submitted a bug that was summarily closed 'by design'. — Spongman, Nov 10 '21 at 03:10
@Spongman I mean that the user filter "works", but everything comes from one user due to the wat that systemd-resolved works (which means that that you can't filter per-user) (Is doesn't bypass iptables, but it breaks certain types of rules (by changing how the traffic is sent)) (I'm not a fan of systemd-resolved) — Gert van den Berg, Nov 10 '21 at 07:09
@GertvandenBerg no, you misunderstand. the user filter is irrelevant. even when not filtering the iptables rule by user, systemd-resolved was still not routed through any iptables rules. — Spongman, Nov 11 '21 at 10:45

score 281 · Accepted Answer · edited Jul 10 '20 at 15:07

281

This method works on the Ubuntu releases 17.04 (Zesty), 17.10 (Artful), 18.04 (Bionic), 18.10 (Cosmic), 19.04 (Disco) and 20.04 (Focal):

Disable and stop the systemd-resolved service:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved

Then put the following line in the [main] section of your /etc/NetworkManager/NetworkManager.conf:

dns=default

Delete the symlink /etc/resolv.conf

rm /etc/resolv.conf

Restart NetworkManager

sudo systemctl restart NetworkManager

Also be aware that disabling systemd-resolvd might break name resolution in VPN for some users. See this bug on launchpad (Thanks, Vincent).

edited Jul 10 '20 at 15:07

Daniel F

293
1
7
19

answered Apr 21 '17 at 05:48

Bastian Voigt

4,696

4

this does not seem to work on Ubuntu 17.04. Alsi, the config file is /etc/NetworkManager/NetworkManager.conf . Name resolving breaks when I do the above. systemd-resolved sucks big time, now the VPN DNS resolving doesn't work properly at all for me. Bug progress can be found here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 – Vincent Gerris Apr 28 '17 at 10:13
@VincentGerris thx! – Bastian Voigt Apr 29 '17 at 17:15
5

I think you should add to the above answer that "apt-get install dnsmasq" should be done once systemd-resolved has been disabled. – LifeBoy Jun 26 '17 at 06:59
2

Just tested on 17.04 and works out-of-the-box (with dnsmasq part of course) – tribbloid Jul 11 '17 at 00:35
8

@LifeBoy I don't use dnsmasq. I just don't use any local nameserver, do not see the value of that. – Bastian Voigt Oct 09 '17 at 09:17
this works for me after reboot – lurscher Oct 26 '17 at 22:51
3

This solution worked for me as a workaround for DNS resolution problem on Ubuntu 17.10. – vahid-dan Nov 01 '17 at 02:35
Worked for me as well on 17.10. Didn't try to use a VPN but everything else works the way it should (including ping and ssh) – springloaded Jan 09 '18 at 21:37
12

For Ubuntu 18.04, all that is needed is to run the commands sudo systemctl disable systemd-resolved.service and sudo service systemd-resolved stop. That worked for me. – Daniel Eagle May 05 '18 at 14:53
rofl how can disabling this break more than having it enabled – Florian Heigl Jul 22 '18 at 17:22
35

Thank you. SystemD is ruining Linux, making it from something reliable and understandable to something that works via magic. – Forbesmyester Aug 14 '18 at 08:24
2

Thanks, on Ubuntu 18.10, I still needed to add dns=default below [main] in /etc/NetworkManager/NetworkManager.conf. – baptx Nov 10 '18 at 16:51
@baptx did you also need to restart network-manager and delete resolv.conf? – Bastian Voigt Nov 13 '18 at 13:38
@BastianVoigt I don't remember exactly but I guess I had to restart network-manager to apply new settings. I don't think I had to remove /etc/resolv.conf because network-manager should rewrite this file for every restart or new connection. – baptx Nov 16 '18 at 21:39
for ubuntu 18.04 you need to reboot after disabling service – S.M.Mousavi Nov 22 '18 at 17:03
I did all the above steps but my /etc/resolv.conf was not re-created even after network-manager restart. I found out that correct and actual resolv.conf was created in /var/run/resolvconf/resolv.conf. So I just created symbolic link from /etc/ and everything started to work perfectly even without system reboot (I'm only used to reboot Windows machines I cannot accept to reboot Linux system) PS: my problem was that systemd-resolved was not resolving minutes after system startup and sometimes after wake-up from sleep. I did not want to invest hours into debugging it. – Juraj Michalak Jan 12 '19 at 11:03
1

This did not work on the latest Ubuntu mini (18.04.11), after a clean install. Don't know what they're doing at ubuntu HQ, but a non resolving dns seems like a really BIG fail to me, /etc/resolv.conf was symlinked to a stub file. Wow. dnsmasq doesn't even start on this OS after apt install dnsmasq. And without a proper mention why it fails. Oh and don't get me started on netplan. Just trying to make a static NIC with dns resolvers in them is like opening a can of worms with that yaml disaster. Sorry I tried ubuntu instead of debian, had to do with debian's old nginx version. – Julius Feb 01 '19 at 11:04
If you are still having problems check if your interface is named eth0. I think I'm seeing a problem when the interface isn't etho, i.e if Predictable Network Interface Names is configured. Or netplan has renamed things. – russau Jun 03 '19 at 02:05
2

We too had issues with Ubuntu 18.04 in office premises where DNS stopped working intermittently. We kept on sudo systemctl restart systemd-resolved. Your option seems working with small change (sudo systemctl restart NetworkManager instead of sudo service network-manager restart) – Amil Waduwawara Jun 22 '19 at 07:21
Running Ubuntu 20.04 in a VM on Ubuntu 19.10 - I used the instructions above - but then had to add /etc/resolv.conf back in - with the entry for my route - in my case "nameserver 192.168.1.1" - then DNS worked perfectly. YMMV. Hope this helps – Nick Mar 27 '20 at 11:11
Thank you, simply wonderful to have control back of my resolv.conf – MitchellK Jul 17 '20 at 07:34
Great, you helped me a lot, thanks! I needed to just reinstall work PC to newer version and stumbled upon systemd-resolved complexity which would block me from working next few days at least. Thanks a lot. – Martin Mucha Nov 09 '20 at 23:28
I am on Ubuntu 20.04 and followed these steps. For once things worked nice but it broke after I restarted my machine. I could see that after the restart the systemd-resolved service was still disabled as before restart but the name resolutions would still fail. – dhruvin Feb 14 '22 at 08:52
you might want to add that the new etc/resolv.conf is generated from /etc/netplan/* settings. – FalcoGer Feb 28 '22 at 01:34
What if I do not have /etc/NetworkManager/NetworkManager.conf ? – Andrew Savinykh Nov 18 '22 at 22:39

BISI · Answer 2 · 2021-05-18T21:20:18.817

43

If you are using Ubuntu 18.04 Server (or Ubuntu 20.04 Server), none of these answers apply. The one by user2427436 comes closest.

The issue is that systemd-resolved is/runs a stub resolver, and I just need to completely disable that (per the question). I need to do this because Zimbra 8.8.15 (FOSS) comes with its own integrated resolver (unbound).

In my situation I am starting from a stock (naive) install of server 18.04, with minimal options on bare metal (well, actually a VM).

so here's the recipe:

   vi /etc/systemd/resolved.conf
     edit line #DNSStubListener=yes
         to be DNSStubListener=no
   systemctl stop systemd-resolved
   systemctl status systemd-resolved
   rm /etc/resolv.conf
   reboot to test...

This is what /etc/systemd/resolved.conf looks like now:

# See resolved.conf(5) for details
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
DNSStubListener=no

that's all it took.

Feel free to install any other resolver you want after this.

edited May 18 '21 at 21:20

answered Dec 10 '19 at 06:47

BISI

722

3

Finally a good answer... I just need Debian Buster/Ubuntu 20.04 LTS to play nice with a real DNSServer... there is no easy way to update systemd-resolved to a version that allows exposing it's forwarding, DNSoverTLS and caching to the LAN. It's becoming a serious issue where 10 year old bad answers in SO still take precedence over correct recent answers – Ray Foss Feb 06 '21 at 18:18
1

Could not agree more about systemd. StackExchange FTW! Just came to amend the answer -- it also works with server 20.04 (same initial conditions). – BISI May 18 '21 at 21:17
"feel free to install any other resolver you want after this" doing what you suggested would disable that system-resolved which is not available in other Linux distros like centos, my question is that does for instance centos have another resolver by default? I want to know whether disabling system-resolved in Ubuntu makes it like centos or do I need to do more than that? – Steve Moretz Mar 11 '23 at 07:29
And also does this work Ubuntu 22? Why did you say server version, doesn't this work with a non server version too? – Steve Moretz Mar 11 '23 at 07:31
as always, the questions are easier than the answers :-/ No, removing systemd-resolved does nothing to make ubuntu into redhat. Your centos question would be better asked on a centos forum.
As for whether the same approach works with the desktop version - try it yourself! As I said in the first line, the previous answers did not work for the server versions of ubuntu. I have not needed to upgrade anyone to server 22.04, nor do a fresh install, so I can't comment beyond wagering a beer that the recipe would work with ubuntu server 22.04. Do let us know about the desktop experiment.
– BISI Mar 13 '23 at 06:26
works on ubuntu server 22.04 – RickyA Nov 27 '23 at 15:20

score 31 · Answer 3 · edited Feb 17 '22 at 17:12

I've recently upgraded to (k)Ubuntu 17.04 and I also stumbled upon the change to systemd.

My setup is fairly typical I think, in that I have a DNS provider in my broadband HUB and this is my primary source of information for all the devices on my network (of which I have a few).

There is some beauty in systemd, it's not all bad but what is really bad is the documentation, the lack of communication from the Ubuntu team and the gung-ho "let's just change it despite it breaks for everyone" mentality.

The solution for me after tearing some hair out was to edit /etc/systemd/resolved.conf:

[Resolve]
DNS=192.168.1.254   # <-- change to your router address
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
Domains=lan         # <-- change to your localdomain name (maybe .local)
#LLMNR=yes  <-- I dabbled with this for a while but it doesn't matter
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp

After not understanding why this wouldn't work I figured out that what was also needed was to switch /etc/resolv.conf to the one provided by systemd. This isn't the case in an out-of-a-box install (for reasons unknown to me).

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

The local DNS server is then not used and all DNS requests are sent to my HUB.

I think this is a much better solution than cutting out and putting in some other solution since systemd-resolv is now the default onwards.

A related problem btw is that the /etc/nsswitch.conf is neutered.

It should read:

hosts:          files mdns4_minimal dns [NOTFOUND=return] resolve [!UNAVAIL=return] dns

This is a confusing configuration since [NOTFOUND=return] means processing ends there. The entries after it will never be used.

And then I have to change the router address in the config everytime I connect to a new WIFI? U serious? -1 — Bastian Voigt, Jul 24 '17 at 07:25
I didn't realise you were roaming with it. If you are, then leave the configuration items commented out. You should then get a /etc/resolv.conf that says:
nameserver 8.8.8.8 nameserver 8.8.4.4 — user2427436, Jul 25 '17 at 18:58
I don't think it's necessary to edit resolved.conf if you set up netplan correctly. i.e., netplan writes the correct values to the symlinked file... PS SYSTEMD SUCKS! — , Jan 07 '19 at 11:56
I prefer taking all the resolver-breakers out. there's usually not more than 2-3 legit resolver updates in 5 years of lifetime of 10000s of servers but guys keep optimizing for a laptop. doesn't matter to them if companies lose millions due to prolonged outages caused by this stuff, and the impact on safety-critical systems is just waved away by "those people will test/optimize it anyway". yup. by removing it. so noone dies. — Florian Heigl, Apr 11 '20 at 16:38
This is not an answer to "How can I disable systemd-resolved in Ubuntu 17.04?" — Robert Riedl, Feb 17 '22 at 16:19

score 4 · Answer 4 · edited Sep 16 '21 at 07:28

4

If you are having leaks issues with your VPN and can't figure out how to set up systemd (like me) you can remove it in the way described in the first answer but don't add the dns=default line because it will activate the nameserver 127.0.0.1. To set the router as dns, create the file "tail" in your /etc/resolvconf/resolv.conf.d/ folder adding the line nameserver 192.168.1.1

do ln -sf /var/run/resolved/resolv.conf /etc/resolv.confif you had messed up with this file.

edited Sep 16 '21 at 07:28

FKEinternet

125

answered Sep 05 '17 at 19:38

Yvain

544
1
4
12

1

Really? For me it works exactly as described in my answer. Definitly not using nameserver 127.0.0.1. I also think it is not very handy to hardcode the IP of your nameserver in a config file. At least I switch wifi networks quite often and each wifi has a different nameserver – Bastian Voigt Sep 06 '17 at 14:42
1

yes 'default' enables 127.0.0.1 as dns – Yvain Sep 08 '17 at 17:33
I think I am wrong here – Yvain Oct 04 '21 at 15:46
Please link to the "first" answer - the order of answers can change... – Gert van den Berg Nov 03 '21 at 15:03

score 1 · Answer 5 · answered Jun 08 '21 at 02:28

1

I feel compelled to add this excellent answer appearing on a dupe, it covers the case where you want the minimal setup of ifupdown + dhclient + resolvconf (yes this is still possible in 2021 in Ubuntu Focal).

This use case isn't covered by the other answers. Maybe we should strive to provide non-systemd-resolved setups for most of the different combinations we could want in our networking stack (netplan-based, networkmanager-based, wicd, and so on).

https://askubuntu.com/a/1336755/32178

answered Jun 08 '21 at 02:28

ata

1,003

That is so not the systemd way! ;-) Maybe you are thinking this is Devuan? https://www.devuan.org/ – BISI Dec 04 '21 at 19:55
@BISI heh, as much as I appreciate the Devuan effort, I still feel a profound satisfaction everytime I can verify that the more mainstream distros continue to be very hackable :) – ata Apr 14 '22 at 19:39

How to disable systemd-resolved in Ubuntu?

5 Answers5

Linked