How to refresh/obtain new DNS servers on Ubuntu Server 20.04?

I work with a "virtual private server" in the cloud, which has Ubuntu 20.04 installed.

I've noticed that - occasionally - when I reboot the server, I cannot ping anything:

$ ping yahoo.com
ping: yahoo.com: Temporary failure in name resolution
$ resolvectl query yahoo.com
yahoo.com: resolve call failed: No appropriate name servers or networks for name found

As far as I understand, since this is Ubuntu 20.04, /etc/resolv.conf is not really used anymore, and systemd overtakes handling of DNS.

But, in any case, I would not want to manually specify DNS servers (as the old trick of putting Google's 8.8.8.8 in /etc/resolv.conf) - apparently, most of the time when DNS works: when the server boots, it somehow "obtains" a DNS server. So, I would like to repeat this process, except I have no idea how.

(By analogy, if I wanted to refresh/obtain new IP address for a machine, I'm aware that the machine should ask the DHCP server for it - so eventually, it is easy to lookup, that in order to do that, I should do sudo dhclient -r eth0 for instance)

Note also, that when DNS name resolution does not work, I do not have DNS Servers listed in this output:

$ systemd-resolve --status
Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (eth0)
      Current Scopes: none
DefaultRoute setting: no
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

I've seen that to clear the DNS cache, they (https://unihost.com/help/how-to-clear-the-dns-cache/) recommend:

sudo /etc/init.d/networking restart

... however, I'd rather not run this command, since I'm connected to the server over ssh, so I imagine that the restart of whole network, would also kill my ssh terminal session, and possibly have other unintended consequences.

So, I am wondering: is there a command I could run in an ssh session, that would refresh or obtain new DNS servers for this machine - using a similar mechanism that is used upon boot, when DNS actually works on this machine?

Solution 1:

Well, I just found https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved which notes:

... somtimes a restart via sudo systemctl restart systemd-resolved is a good idea.

So, I did try this command:

sudo systemctl restart systemd-resolved

... and indeed, DNS Servers appeared then in the output of systemd-resolve --status (or resolvectl status, which seems to show the same report)

Other possibilites:

On Ubuntu 20.04, systemd-resolved is a local DNS server included with systemd that acts as a stub resolver and it should automatically edit /etc/resolv.conf with the correct config.

...

This file contains DNS servers from DHCP leases but be aware that you will not benefit from the stub resolver caching feature.

Ah, if DNS servers are obtained from DHCP leases - then there is a possibility sudo dhclient -r eth0 might work, as well.

Finally, I dared to run:

$ sudo /etc/init.d/networking restart
Restarting networking (via systemctl): networking.service.

... and it turns out, this did not break my ssh session, so that is nice as well.