Introduction

Hostname lookup failure Linux usually means the system cannot resolve a name through the path it currently expects: local hosts file, NSS, systemd-resolved, or upstream DNS. The key is to figure out whether the failure is local resolver config, DNS reachability, or a mismatch in how the hostname should be resolved.

Symptoms

  • Commands like ping, curl, or package managers fail with hostname lookup errors
  • Some names resolve while others do not
  • The issue appears after network, VPN, or DNS changes
  • /etc/resolv.conf contents do not match what you expect

Common Causes

  • The resolver points at an unreachable or wrong DNS server
  • /etc/hosts or nsswitch.conf changed the lookup order unexpectedly
  • systemd-resolved or NetworkManager rewrote resolver state
  • VPN or split-DNS configuration overrides the normal resolver path

Step-by-Step Fix

  1. 1.Test the failing name with multiple tools
  2. 2.Compare getent, nslookup, and dig so you can see whether the failure is in NSS or upstream DNS.
bash
getent hosts example.internal
nslookup example.internal
dig example.internal
  1. 1.Inspect resolver configuration
  2. 2.Check resolv.conf, nsswitch.conf, and whether systemd-resolved is in the path.
bash
cat /etc/resolv.conf
cat /etc/nsswitch.conf
resolvectl status
  1. 1.Check local overrides
  2. 2.Confirm the name is not being shadowed or missed in /etc/hosts.
bash
grep example.internal /etc/hosts
  1. 1.Retest against a known DNS server
  2. 2.If local config looks correct, query a trusted resolver directly and compare results.

Prevention

  • Keep resolver ownership clear when using systemd-resolved, NetworkManager, and VPN tooling together
  • Document split-DNS behavior for internal hostnames
  • Test both NSS and upstream DNS when changing lookup configuration
  • Watch for resolver drift after network automation changes