Hostnames cannot be resolved after upgrading to 22.04

Question

After upgrading ubuntu from 21.10 to 22.04, my internet connection does not work anymore. I am connected to the WLAN and I can ping IP addresses (from the local network as well as from the internet) - however, resolving names does not work anymore. So ping 151.101.65.69 works with 0% packet loss but ping askubuntu.com gives me an error Name or service not known (it works from another machine that is connected to the same router).

When running nmcli, it shows the following DNS configuration:

DNS configuration:
    servers: 192.168.17.1
    domains: fritz.box
    interface: wlp64s0

I also tried manually adding 8.8.8.8 to the DNS servers in the network manager (WiFi setting -> IPv4 -> DNS). Then, both servers are shown in the DNS configuration but the problem still persists.

Any idea what the reason could be, what I can do to narrow down the problem or how to solve it?

Answer 1

As pointed out in this answer and in this answer, the solution (at least in my case) was a problem with /etc/resolv.conf which only contained a commented out line "Generated by NetworkManager". Replacing that file with a symlink to /run/resolvconf/resolv.conf solved the problem for me:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

Answer 2

This seems to be caused by Ubuntu 22.04 expecting to be configured via netplan. Netplan configuration is created on a fresh install, but if you've an upgraded system, the necessary configurations are not present.

If there is no configuration file (check ls /etc/netplan/*.yaml) on your system, you will not get a DNS resolver configured by default.

All of the hack recommendations to override systemd-resolved service unit or the /etc/resolv.conf directly are just covering up the symptom.

Possible files that may(should) be present on your system - run ip a and ip r and replace values and device names as required:

Default generic config created by subiquity which will probably suffice unless you have specific needs
/etc/netplan/00-installer-config.yaml

network:
  ethernets:
    eno1:
      dhcp4: true
  version: 2

LXD container config with hardcoded IPv4, gateway and DNS resolvers
/etc/netplan/50-cloud-init.yaml

network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.0.0.50/16]
      routes:
      - to: default
        via: 10.0.0.1
      nameservers:
        addresses: [10.0.0.11,10.0.0.12]

Example of a bond setup
/etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
      dhcp6: no
    eno2:
      dhcp4: no
      dhcp6: no
  bonds:
    bond0:
      interfaces: [eno1,eno2]
      dhcp4: no
      dhcp6: no
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100
  bridges:
    br0:
      interfaces: [bond0]
      addresses: [10.0.0.100/16]
      routes:
      - to: default
        via: 10.0.0.1
      nameservers:
        addresses: [10.0.0.11,10.0.0.12]

Run netplan apply afterwards to ensure you still have connectivity (careful with running this on servers you have no other access to!) or reboot.

Answer 3

For me, the problem was that /etc/resolv.conf was linked to a stub resolver (/run/systemd/resolve/stub-resolv.conf) instead of the usual one (/run/systemd/resolve/resolv.conf).

Check the target of the /etc/resolv.conf symlink to see if yours is the same.

I fixed this like so:

ls /run/systemd/resolve/resolv.conf && sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved

First line includes a guard so the whole operation will fail if you don't have /run/systemd/resolve/resolv.conf for some reason. Hope this helps!

Answer 4

Wow, I just found a very different explanation for dns breaking on an upgrade to 22.04.

I was using dnsmasq with NetworkManager. The setup used to work fine, but I had a line like this:

local=/example.com/1.1.1.1

And after the upgrade it would return 1.1.1.1 as the IP when I tried to ping example.com

Before the upgrade it would use 1.1.1.1 as the DNS server and return the resolved IP address.

I changed the line to:

server=/example.com/1.1.1.1

And it went back to resolving correctly using the DNS server.

The man page for dnsmasq did not change, but the behavior seems to have changed. Quoting the man page:

Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is
local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain
to any upstream servers.  --local is a synonym for --server to make configuration files clearer in this
case.

But it seems now that local is only a synonym for server in the case where you don't list an IP address. Before it was an alias for server even in the case where you did specify an IP address. I wish they had updated the man pages or changed the behavior to error out if you specify an IP address with local=, since this change breaks previously working--albeit ambiguous--configurations.

Answer 5

I had issue with same symptoms. I tracked it down to ifupdown/managed=false in

/etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=false

Changing this to true resolved the issue.