I have an Odroid C2 - a single board computer running 18.04 minimal for ARM. Originally, it was using NetworkManager + systemd-resolved to manage network connections, but since I use only Ethernet and always connected to the same network, I find it a little bit overkill, so I disable both of them and moved to Netplan. Here is my /etc/netplan/02-networkd.yaml:

  version: 2
  renderer: networkd
      dhcp4: yes

As you can see, it is a simple DHCP configuration. Here is the result of using that config:

# netplan ip leases eth0

IP address and all interface parameters set correct. The only problem I have is with DNS. I found that netplan does not update /etc/resolve.conf even it has all obligatory information in the leas.

Is there a way to make Netplane update/configure /etc/resolve.conf with DNS information it receives from DHCP without using NetworkManager or resolved? Here is some additional info:

# ls -lA /etc/resolv.conf
-rw-r--r-- 1 root root 20 Apr 21 00:13 /etc/resolv.conf

# cat /etc/resolv.conf 
search vault
  • Edit your question and show me ls -al /etc/resolv.conf and cat /etc/resolv.conf and resolvectl (or system-resolve --status). Start comments to me with @heynnema or I may miss them.
    – heynnema
    Commented Apr 20, 2019 at 20:20
  • @heynnema current resolv.conf is just a regular hand-written file. It seems that this installation is missing both resolvectl and system-resolve.
    – e-pirate
    Commented Apr 20, 2019 at 21:19
  • Oops. A typo by me. The correct command is systemd-resolve --status. Give me a couple of minutes to put together a quick answer for you. Are you using VPN?
    – heynnema
    Commented Apr 20, 2019 at 21:25
  • @heynnema the systemd-resolved is down, my question is how to make netplan manage resolve.conf without external services like resolved and NetworkManager.
    – e-pirate
    Commented Apr 20, 2019 at 21:45
  • Did you disable systemd-resolved? I just looked back and I see that you did. That and/or dnsmasq manage DNS, and /etc/resolv.conf.
    – heynnema
    Commented Apr 20, 2019 at 21:54

8 Answers 8


It is a deliberate design decision that netplan delegates management of resolver configuration to systemd-resolved. There is no support in netplan for directly managing /etc/resolv.conf based on answers to dhcp queries. Indeed, systemd-networkd expects to pass this information to systemd-resolved and netplan relies on this behavior.

  • So, I need a whole service just to maintain a single file in up to date state? Why?
    – e-pirate
    Commented Apr 20, 2019 at 19:22
  • The function of systemd-resolved is not to maintain /etc/resolv.conf. The function of systemd-resolved is to make it unnecessary to maintain /etc/resolv.conf, because having a resolv.conf file that changes makes name resolution unreliable across the life cycle of a system (especially for e.g. long-lived chroots, containers, etc), and also a local resolver is capable of detecting when an upstream nameserver is down and provide better behavior when compared with the in-process glibc behavior.
    – slangasek
    Commented Apr 22, 2019 at 1:26
  • The user is not prevented from using netplan when systemd-resolved is absent. On my Ubuntu Server 20.04, with netplan in charge but systemd-resolved stopped, the network works normally except that /etc/resolv.conf does not get automatically maintained. Installing the resolvconf package solves that problem.
    – Syncopated
    Commented Jan 11, 2023 at 15:25

There appears to be a lot of confusion between resolvconf, systemd-resolved and /etc/resolv.conf. Here's my 2 cents:

Ubuntu 18.04 uses systemd-resolved for name resolution. As @slangasek correctly pointed out, netplan delegates name resolution to systemd-resolved. For systemd-resolved to work properly, /etc/resolv.conf needs to point to /run/systemd/resolve/stub-resolv.conf.

However, if you also have the resolvconf package installed on the system, the symlink /etc/resolv.conf will incorrectly point to /run/resolvconf/resolv.conf. This will result in name resolution failures, e.g. "Temporary failure in name resolution" error. Manual editing of /etc/resolv.conf is not recommended. The simplest resolution is to remove the resolvconf package. This will reset the symlink and all will be well (you may require a reboot or at least restart the systemd-resolved service).


I see it a lot. Users have removed the symlink for /etc/resolv.conf, and put a hand-written file there. There's actually three different places that this symlink refers to, and I'll give you the most common one...

In terminal...

cd /etc # change directory

sudo mv resolv.conf resolv.conf.BAK # rename the current resolv.conf as a backup file

sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf # recreate standard symlink

Note: do not manually edit /etc/resolv.conf!

  • systemd-resolved mast be up for the method, while I want to get rid of any 'external' services and make netplan manage resolev.conf by itself.
    – e-pirate
    Commented Apr 20, 2019 at 21:49
  • @e-pirate doesn't work that way... and... you use dhcp4, so you do rely on external services now.
    – heynnema
    Commented Apr 20, 2019 at 21:55
  • DHCP client is a mast-have in that chain, as well as something to handle interface configuration on the client side, while resolved is just a mediator between dhcp and resolv.conf. In Gentoo I don't need any external service to the system, that manages network interfaces (ipupdown AFAIR), it will write data from dhcp lease to resolv.conf. I expected netplan to handle that, but it seems that netplan needs an external DNS handler like resolved.
    – e-pirate
    Commented Apr 20, 2019 at 22:11

Have you tried static settings

A simple edit to /etc/NetworkManager/NetworkManager.conf and disabling systemd-resolved.service (as in this answer https://askubuntu.com/a/907249/719422). But that alone, while essential, does not guarantee tamper-proof resolv.conf.

Do this as SuperUser:

echo nameserver > /etc/resolv.conf
chattr -e /etc/resolv.conf
chattr +i /etc/resolv.conf

There actually a lot of confusion between netplan(/etc/netplan/*.yaml), systemd-resolved(/etc/systemd/resolved.conf) and /etc/resolv.conf. When configuring the network with netplan, if ping pass but the domain resolve failed, check /run/systemd/resolve/resolv.conf, this file is usually generated from /etc/systemd/resolved.conf. Latest ubuntu using netplan to configure network, while the older use /etc/network/interfaces


I have the same problem on Ubuntu Server 20.04. (Unlike Desktop, Server does not use NetworkManager, so the answer to a related question for Desktop does not apply: https://askubuntu.com/a/907249/644076)

The network is configured using netplan. I disabled and stopped systemd-resolved because my router's DNS works just fine and I do not want additional complications from systemd-resolved, which I have experienced many times. Because systemd-resolved was gone, I also removed the symlink /etc/resolv.conf that pointed to /run/systemd/resolve/stub-resolv.conf.

But when I restarted systemd-networkd, /etc/resolv.conf did not get created.

Thanks to inspiration from another answer (https://askubuntu.com/a/1241298/644076), I installed the resolvconf package and it just works. I did not configure anything and a symlink /etc/resolv.conf pointing to /run/resolvconf/resolv.conf with the correct content appeared.


I had the same problem (Ubuntu 22.04 LTS Server and Desktop) and I was looking for any solutions. I tested the @Syncopated solution but it doesn't work in my case. I followed this mini-guide (in Spanish) and I got it.

You have to erase the /etc/resolv.conf and copy it from /run/systemd/resolve/resolv.conf. Similar to the way that other partners were saying but, at least in my case, with a different source.

$ sudo rm -f /etc/resolv.conf

$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

In Ubuntu 24.04 I found NetworkManager stuck the nameserver info in /run/NetworkManager/no-stub-resolv.conf so a symbolic link to it in /etc/resolv.conf did the trick

ln -s /run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .