Cum se reîmprospătează/obțin noi servere DNS pe Ubuntu Server 20.04?

Lucrez cu un „server privat virtual” în cloud, care are instalat Ubuntu 20.04.

Am observat că - ocazional - când repornesc serverul, nu pot da ping la nimic:

$ ping yahoo.com
ping: yahoo.com: Eșec temporar în rezolvarea numelui
$ resolvectl interogare yahoo.com
yahoo.com: rezolvarea apelului eșuat: nu au fost găsite servere de nume sau rețele adecvate pentru nume

Din câte am înțeles, deoarece acesta este Ubuntu 20.04, /etc/resolv.conf nu se mai folosește cu adevărat și systemd depășește gestionarea DNS.

Dar, în orice caz, nu aș dori să specific manual serverele DNS (ca vechiul truc de a pune 8.8.8.8 de la Google în /etc/resolv.conf) - aparent, de cele mai multe ori când funcționează DNS: când pornește serverul, „obține” cumva un server DNS. Așadar, aș dori să repet acest proces, doar că nu am idee cum.

(Prin analogie, dacă vreau să reîmprospăt/obțin o nouă adresă IP pentru o mașină, sunt conștient că mașina ar trebui să o solicite serverului DHCP - așa că în cele din urmă, este ușor de căutat, că pentru a face asta, am ar trebui sa faci sudo dhclient -r eth0 de exemplu)

Rețineți, de asemenea, că atunci când rezoluția numelui DNS nu funcționează, nu am Servere DNS enumerate în această ieșire:

$ systemd-resolve --status
Global
       Setarea LLMNR: nr
Setare MulticastDNS: nu
  Setare DNSoverTLS: nu
      Setare DNSSEC: nu
    DNSSEC suportat: nu
          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
                      Acasă
                      intern
                      intranet
                      lan
                      local
                      privat
                      Test

Link 2 (eth0)
      Domenii curente: niciuna
Setare DefaultRoute: nu
       Setare LLMNR: da
Setare MulticastDNS: nu
  Setare DNSoverTLS: nu
      Setare DNSSEC: nu
    DNSSEC suportat: nu

Am văzut că pentru a șterge memoria cache DNS, ei (https://unihost.com/help/how-to-clear-the-dns-cache/) recomanda:

sudo /etc/init.d/networking restart

... cu toate acestea, aș prefera să nu rulez această comandă, deoarece sunt conectat la server ssh, așa că îmi imaginez că repornirea întregii rețele, mi-ar ucide, de asemenea ssh sesiune terminală și poate avea alte consecințe nedorite.

Deci, mă întreb: există o comandă pe care aș putea să o rulez într-un ssh sesiune, care ar reîmprospăta sau obține noi servere DNS pentru această mașină - folosind un mecanism similar care este utilizat la pornire, când DNS funcționează de fapt pe această mașină?

Ei bine, tocmai am găsit https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved care noteaza:

... uneori o repornire prin sudo systemctl restart systemd-rezolvat este o idee bună.

Deci, am încercat această comandă:

sudo systemctl restart systemd-rezolvat

... și într-adevăr, Servere DNS a apărut atunci în ieşirea din systemd-resolve --status (sau starea resolvectl, care pare să arate același raport)

Alte posibilitati:

Pe Ubuntu 20.04, systemd-rezolvat este un server DNS local inclus cu systemd care acționează ca un solutor stub și ar trebui să editeze automat /etc/resolv.conf cu configurația corectă.

...

Acest fișier conține servere DNS din contracte de închiriere DHCP, dar rețineți că nu veți beneficia de funcția de stocare în cache a stub resolver.

Ah, dacă serverele DNS sunt obținute din contracte de închiriere DHCP - atunci există o posibilitate sudo dhclient -r eth0 ar putea funcționa, de asemenea.

În sfârșit, am îndrăznit să alerg:

$ sudo /etc/init.d/networking restart
Repornirea rețelei (prin systemctl): networking.service.

... și se pare că asta nu mi-a rupt ssh sesiune, deci este frumos și asta.