When systemd‑resolved ignores /etc/hosts after a kernel upgrade: how to fix it

Why /etc/hosts suddenly stops being respected after a kernel upgrade

When a kernel upgrade lands, you expect only low‑level changes. In practice, the upgrade can ripple through the entire userland, especially when systemd‑resolved is involved. A common symptom is that hostname lookups that used to resolve via /etc/hosts now fall back to DNS or fail entirely. The culprit is often a subtle change in how systemd‑resolved loads its configuration or how the Name Service Switch (NSS) library consults /etc/hosts.

Below is a step‑by‑step guide that walks through the problem, shows how to diagnose it, and provides several robust fixes. The examples are taken from a recent Debian 12 upgrade to kernel 6.6, but the same pattern applies to Fedora, Arch, OpenSUSE, and other distributions that ship systemd‑resolved.

1. The anatomy of hostname resolution in systemd‑based systems

systemd‑resolved runs as a system service. It listens on the stub port 53 (127.0.0.53) and provides DNS caching, DNS‑SEC validation, and local hostname resolution. The stub resolver is enabled by default, and /etc/resolv.conf is usually a symlink to its stub file.

When a program calls getaddrinfo(), the NSS library consults /etc/nsswitch.conf. If the files keyword is present, it reads /etc/hosts first. Only if that lookup fails does it forward the query to the stub resolver, which in turn may query upstream DNS servers.

2. What changed after the kernel upgrade?

A kernel upgrade can:

1. Replace the libc implementation – the new libc may load a different NSS module order.
2. Alter the initramfs – if systemd‑resolved is packaged in the initramfs, the new kernel may bring a newer version of the service.
3. Modify the systemd binary – a newer systemd may change default configuration files, such as /etc/systemd/resolved.conf.

In many cases, the kernel upgrade triggers a re‑installation of systemd packages. The new systemd‑resolved binary may have a different default for the Cache=yes or DNSStubListener=yes options, causing the stub resolver to be disabled or misconfigured.

3. Symptoms to look for

If you notice any of these, start with the following diagnostics.

4. Diagnostics checklist

1. Verify the service status

   systemctl status systemd-resolved
   

   Look for Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) and Active: active (running).

2. Check the stub resolver configuration

   systemd-resolve --status
   

   The output should contain a section like:

   DNS Server: 127.0.0.53
   DNS Server: 2001:4860:4860::8888
   

   If the DNS Server: 127.0.0.53 line is missing, the stub listener is disabled.

3. Inspect /etc/nsswitch.conf

   grep hosts /etc/nsswitch.conf
   

   The line should include files before dns. Example:

   hosts: files mdns4_minimal [NOTFOUND=return] dns
   

   If files is missing, /etc/hosts will never be consulted.

4. Confirm /etc/resolv.conf points to the stub

   ls -l /etc/resolv.conf
   

   Expected:

   lrwxrwxrwx 1 root root 39 Sep 16 12:34 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
   

   If it points elsewhere, DNS queries may bypass systemd‑resolved.

5. Check the actual /etc/hosts file

   cat /etc/hosts
   

   Ensure the entries are correct and that the file is readable by all users (mode 644). A common mistake is accidentally changing the file to 600, which prevents non‑root programs from reading it.

6. **Look at

See also

• Adding per‑interface DNS search domains to systemd‑resolved on Ubuntu 24.04
• Using journalctl to Track Down the Hidden ‘eth0’ Carrier Lost Messages That Cause Network Flaps After a Kernel Upgrade
• Rebuilding initramfs to exit emergency mode after a kernel update on Ubuntu 24.04
• How to Extract a Single File from a Borg Backup Archive Without Recreating the Entire Directory Tree
• Configure systemd’s OnFailure to email me when my daily backup service dies