7

I'm renting a VPS from Linode with Ubuntu 20.04 LTS (Focal Fossa) installed on it. But the default DNS server from Linode doesn't resolve a domain name which I really need it to resolve. Therefore, I tried to edit my netplan configuration to change the DNS server to Google's one, since the VPS is obviously headless. I edited the file /etc/netplan/01-netcfg.yaml to contain the following:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: yes
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

Ubuntu 20.04 was using networkd as the netplan backend by default. I linted the YAML and it is correctly formatted. DHCP is on by default (as by setting dhcp4: yes) and turning it off (by setting dhcp4: no) does not correct the problem. eth0 is the name of my network connection as per ip a. However, whenever I run sudo netplan apply after saving the netplan configuration file the active nameserver does not seem to change as per sudo systemd-resolve --status. Even forcing networkd to restart by running sudo ip link set eth0 down and sudo ip link set eth0 up or restarting systemd-resolved by running sudo systemctl restart systemd-resolved does nothing.

Why is it so difficult to change the DNS server on Ubuntu Server 20.04 LTS? Am I missing something here?

Thank you so much in advance for your help,
Joshua

EDIT: Output of sudo lshw -C network:

  *-network
       description: Ethernet controller
       product: Virtio network device
       vendor: Red Hat, Inc.
       physical id: 4
       bus info: pci@0000:00:04.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: msix bus_master cap_list rom
       configuration: driver=virtio-pci latency=0
       resources: irq:20 ioport:c080(size=64) memory:febd3000-febd3fff memory:fe
008000-fe00bfff memory:feb80000-febbffff
     *-virtio2
          description: Ethernet interface
          physical id: 0
          bus info: virtio@2
          logical name: eth0
          serial: f2:3c:93:91:e5:ed
          capabilities: ethernet physical
          configuration: autonegotiation=off broadcast=yes driver=virtio_net
driverversion=1.0.0 ip=170.187.185.46 link=yes multicast=yes

Output of sudo ls -al /etc/resolv.conf:

lrwxrwxrwx 1 root root 37 Feb 24 06:53 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

Output of sudo cat /etc/resolv.conf:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53 options edns0 trust-ad search members.linode.com

Output of sudo cat /etc/network/interfaces:

# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#    sudo apt install ifupdown

Output of cat /etc/netplan/*.yaml:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

3 Answers3

9

Go to https://netplan.io/reference/ and review the section on DHCP Overrides.

/etc/netplan/01-netcfg.yaml...

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

sudo netplan generate

sudo netplan apply

reboot # if required

heynnema
  • 73,649
2

The problem here is that by default systemd will not search for hostnames on the local network. To fix this you need to edit your netplan config file to include a search field in your name servers.

So for example to search on a local domain named tacos.local you need to make it look like this if your name servers were 192.168.1.1 and .2. This however also gives you back a non authoritative answer for some reason as well.

nameservers: 
       search: [tacos.local]
       addresses: [192.168.1.1,192.168.1.2]
David DE
  • 2,316
0

The following command shows that /etc/resolve.conf points to the stub resolver, which is a local caching nameserver.

sudo ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Feb 24 06:53 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

If you want to you use the uplink nameserver, simply change what file the symlink /etc/resolv.conf points to: /run/systemd/resolve/resolv.conf.

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

This is outlined in the man page for systemd-resolved: systemd-resolved manpage

/ETC/RESOLV.CONF         top
   Four modes of handling /etc/resolv.conf (see resolv.conf(5)) are
   supported:

   •   systemd-resolved maintains the
       /run/systemd/resolve/stub-resolv.conf file for compatibility
       with traditional Linux programs. This file lists the
       127.0.0.53 DNS stub (see above) as the only DNS server. It
       also contains a list of search domains that are in use by
       systemd-resolved. The list of search domains is always kept
       up-to-date. Note that /run/systemd/resolve/stub-resolv.conf
       should not be used directly by applications, but only through
       a symlink from /etc/resolv.conf. This file may be symlinked
       from /etc/resolv.conf in order to connect all local clients
       that bypass local DNS APIs to systemd-resolved with correct
       search domains settings. This mode of operation is
       recommended.

   •   A static file /usr/lib/systemd/resolv.conf is provided that
       lists the 127.0.0.53 DNS stub (see above) as only DNS server.
       This file may be symlinked from /etc/resolv.conf in order to
       connect all local clients that bypass local DNS APIs to
       systemd-resolved. This file does not contain any search
       domains.

   •   systemd-resolved maintains the
       /run/systemd/resolve/resolv.conf file for compatibility with
       traditional Linux programs. This file may be symlinked from
       /etc/resolv.conf and is always kept up-to-date, containing
       information about all known DNS servers. Note the file
       format's limitations: it does not know a concept of
       per-interface DNS servers and hence only contains system-wide
       DNS server definitions. Note that
       /run/systemd/resolve/resolv.conf should not be used directly
       by applications, but only through a symlink from
       /etc/resolv.conf. If this mode of operation is used local
       clients that bypass any local DNS API will also bypass
       systemd-resolved and will talk directly to the known DNS
       servers.

   •   Alternatively, /etc/resolv.conf may be managed by other
       packages, in which case systemd-resolved will read it for DNS
       configuration data. In this mode of operation
       systemd-resolved is consumer rather than provider of this
       configuration file.

   Note that the selected mode of operation for this file is
   detected fully automatically, depending on whether
   /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf
   or lists 127.0.0.53 as DNS server.

mpboden
  • 3,046