Control name-to-IP mapping on a single Linux host quickly and predictably. 16.11.2025 | reading time: 2 min Local name resolution decides which IP a hostname maps to; learn to control that mapping locally so services resolve predictably, whether by editing the hosts file, tuning the resolver, or inspecting lookup order. Hands-on example Add a local name and verify resolution with these commands and their outputs: ```bash echo "10.0.0.42 app.internal" | sudo tee -a /etc/hosts getent hosts app.internal # output # 10.0.0.42 app.internal ping -c1 -W1 app.internal # output # PING app.internal (10.0.0.42) 56(84) bytes of data. # 64 bytes from 10.0.0.42: icmp_seq=1 ttl=64 time=0.34 ms # --- app.internal ping statistics --- # 1 packets transmitted, 1 received, 0% packet loss, time 0ms ``` Inspecting lookup order The order resolver uses is set in /etc/nsswitch.conf; a typical line is "hosts: files dns myhostname" which means the system checks /etc/hosts before DNS; use `getent hosts name` to see what the C library returns and `cat /etc/nsswitch.conf` to confirm order. Caching and resolver services Be aware of caching layers and resolver daemons: `nscd` or `systemd-resolved` can cache name answers, `resolvectl status` or `systemd-resolve --status` shows per-link behavior, and a local `dnsmasq` can provide LAN-wide overrides. When to choose which method Use /etc/hosts for fast, per-host overrides and debugging; set the system hostname with `hostnamectl set-hostname` for local identity; deploy dnsmasq or a local DNS for many hosts; use Avahi for mDNS on dynamic LANs. Final perspective Mastering local resolution reduces surprises when services fail to connect and accelerates troubleshooting of name-related issues; keep changes documented and prefer centralized DNS for production scale, then explore deeper Linux networking topics and certification paths. Join Bits & Bytes Academy First class LINUX exam preparation. network utilities troubleshooting infrastructure
