DNS resolver inconsistency between Ubuntu 18.04.3 (LTS) x64 and 20.04 (LTS) x64 droplets


I believe there is a problem with the default configuration of the Ubuntu 20.04 LTS droplet on DigitalOcean…

As I’m sure you’re aware, back in Ubuntu 16.04, the package resolvconf managed the contents of /etc/resolv.conf (hence the DO NOT EDIT warnings of the past we all remember)

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

Since Ubuntu 18.04 however, the systemd-resolved package has replace resolvconf.

The systemd-resolved package runs a local stub DNS resolver on The intention is that /etc/resolv.conf points to and so any program on the system attempting to perform name resolution will hit the local DNS stub resolver, at which point systemd-resolved will intercept the query and forward or answer the question as configured, and as appropriate.

This means the user can specific different DNS server search orders, prior to, for example using the static, or DHCP assigned DNS servers, or express a preference to use a DNS server available via a VPN tunnel for example.

In the default Ubuntu 18.04.3 (LTS) x64 droplet, this is configured as expected. /etc/resolv.conf contains the directive which directs queries to the local stub resolver:

options edns0

And in the static IP address configuration defined in /etc/netplan/50-cloud-init.yaml we see the DigitalOcean nameservers statically assigned to the eth0 interface:


The Ubuntu 18.04 DigitalOcean droplet works as expected.

The problem is that the Ubuntu 20.04 LTS DigitalOcean droplet does not follow this pattern.

If we create a new Ubuntu 20.04 LTS droplet, we see that, as before /etc/netplan/50-cloud-init.yaml contains the static nameserver addresses


But /etc/resolv.conf is not using the local stub resolver and instead has been configured to use Google name servers.

nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

If we then interrogate the system using resolvectl dns we can see the inconsistency come to light.

Global: 2001:4860:4860::8888 2001:4860:4860::8844
Link 2 (eth0):

On the one hand, eth0 interface is statically assigned to use the DigitalOcean name servers, and on the other, there is a global configuration override to ignore systemd-resolved and the local stub resolver and instead direct all DNS queries out to Google’s name servers.

This configuration seems sub-optimal for a number of reasons.

  1. The configuration only points to one of Google’s IPv4 name servers.
  2. Any transit or connectivity problems between DigitalOcean and Google knocks out name resolution for DigitalOcean customers across the board running Ubuntu 20.04 LTS and is then out of your control as a company and engineering team.
  3. Lastly, but by far most importantly, this configuration completely overrides any configuration made to systemd-resolved as applications on the the local system fail to interact with the local stub resolver.

May I request that you investigate why the default behaviour of the DNS resolver has changed in the DigitalOcean Ubuntu 20.04 LTS droplet and either

a) Fix the default configuration of /etc/resolv.conf to match 18.04 LTS or, b) Help me (and the community) understand your reasoning for this assumption-breaking change.

Many thanks in advance.

Kind regards, Marc

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

@efox any update here?


My name is Daniel and I work on the team that manages how images are brought onto the DO platform for use. Our team has been working on improving how images are built and tested before they are released to everyone at DO. It looks like as part of that effort, we accidentally included an out of date etc/resolve.conf file. We have removed the file, and will ensure that this doesn’t happen again.

Sorry for the confusion, Daniel.

This comment has been deleted