Hi.
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)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Since Ubuntu 18.04 however, the systemd-resolved
package has replace resolvconf
.
The systemd-resolved
package runs a local stub DNS resolver on 127.0.0.53. The intention is that /etc/resolv.conf
points to 127.0.0.53
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:
nameserver 127.0.0.53
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:
nameservers:
addresses:
- 67.207.67.3
- 67.207.67.2
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
nameservers:
addresses:
- 67.207.67.3
- 67.207.67.2
But /etc/resolv.conf
is not using the local stub resolver and instead has been configured to use Google name servers.
nameserver 8.8.8.8
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: 8.8.8.8 2001:4860:4860::8888 2001:4860:4860::8844
Link 2 (eth0): 67.207.67.3 67.207.67.2
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.
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
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!
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.
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?
Hello!
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