DNS Resolution on Linux: resolv.conf and hosts

Every time your server connects to a hostname, it performs DNS resolution. Most of the time this is transparent, so when DNS breaks, the failure is confusing because the network seems fine. Ping an IP works, but ping a hostname fails. Understanding the complete resolution pipeline on modern Linux lets you diagnose these issues in minutes instead of guessing.

The Resolution Stack

On a modern systemd-based distribution, name resolution flows through several layers. A typical modern setup uses systemd-resolved as the resolver, which caches answers, talks to upstream DNS servers, and handles per-interface configuration. The classic resolv.conf still exists but is often a symlink managed by systemd-resolved or NetworkManager.

The hosts file is consulted first within the resolution order configured in nsswitch.conf. The order is controlled by the /etc/nsswitch.conf line for hosts. A typical line reads hosts: files dns, meaning local files first, then DNS.

cat /etc/nsswitch.conf
cat /etc/resolv.conf
readlink -f /etc/resolv.conf

The readlink reveals whether resolv.conf is a real file or a symlink to a systemd-resolved stub. If it points to /run/systemd/resolve/stub-resolv.conf, local processes are sending queries to the systemd-resolved local stub at 127.0.0.53.

Systemd-resolved and Its Modes

systemd-resolved supports multiple DNS modes. In direct mode, it passes queries to configured upstream servers. In stub mode, it presents 127.0.0.53 as the local nameserver and forwards to real DNS servers. The mode affects how you inspect and change DNS.

resolvectl status
resolvectl query netbayhosts.in
resolvectl statistics

The resolvectl status command shows which interfaces have which DNS servers, current domains, and the cache state. resolvectl query resolves a name through the systemd-resolved cache and shows where the answer came from. The statistics command shows cache hit rates, which matter when tuning performance.

Configuring DNS in /etc/resolv.conf

When you manage DNS manually, edit /etc/resolv.conf directly with nameserver lines, but only if it is a regular file and not managed by a resolver. If any daemon owns the file, your edits get overwritten at reboot.

nameserver 1.1.1.1
nameserver 8.8.8.8
search netbayhosts.in home.local
options timeout:1 attempts:2

The search directive appends these domains when a name is not fully qualified, which is convenient but can add confusing latency when the first search domain fails. The options line tunes timeout and retry behavior. On a VPS these tweaks are the difference between a 200 millisecond DNS failure and a multi-second hang.

The Hosts File

The /etc/hosts file maps hostnames to addresses without any network traffic. It is instant, offline, and has the highest priority when files is first in nsswitch.

127.0.0.1 localhost
10.0.0.25 db.internal netbayhosts.in
::1 localhost ip6-localhost

Use the hosts file for static infrastructure mappings that never change, or to pin a hostname to a specific address and bypass DNS quirks. It is also where you fight IPv6 resolution issues: if a hostname only resolves to a MAC address magically in your container environment, the hosts file can force the correct mapping.

The first white-space-separated field is the address, the rest are aliases. Keep it tidy, because a misformatted line can break resolution for the entire system.

Tracing the Full Path with dig and getent

To see what upstream DNS thinks, use dig directly against a nameserver, bypassing the local resolver.

dig @1.1.1.1 netbayhosts.in A
dig +short netbayhosts.in
getent hosts netbayhosts.in
getent ahosts netbayhosts.in

dig queries the specified server and shows the full answer including TTIs and authoritative data. getent uses the system resolver exactly as applications do, including the hosts file and nsswitch order. Comparing the two tells you whether the local system or the upstream DNS server is responsible for a discrepancy. If getent returns a different answer than dig, the local cache or hosts file is overriding DNS.

Diagnosing Common DNS Failures

The classic symptom is applications failing with unknown hostname errors while IP connectivity works. First check that /etc/resolv.conf points at a reachable nameserver. Then test raw DNS with dig against a public server to isolate whether the problem is your upstream or your own resolver.

ping -c 1 1.1.1.1
dig @1.1.1.1 example.com
systemctl status systemd-resolved

If dig against 1.1.1.1 works but local resolution fails, the problem is your local resolver configuration or cache. Flush the cache with resolvectl flush-caches, then retry. If order in nsswitch.conf puts files before dns and your hosts file has a stale entry, that stale entry wins every time.

DNS on a Server vs a Desktop

On a server you want deterministic, low-latency DNS. That means choosing good upstream nameservers, enabling caching with systemd-resolved or a local resolver, and keeping hosts file entries minimal. You also want reliable timeout behavior so a dead DNS server does not stall every connection for seconds.

A good production setup pins two reliable public nameservers, configures a short search domain list, and relies on the systemd-resolved cache to absorb repeated resolution. This keeps connection setup fast and predictable.

You can test the full DNS stack on a fresh Netbay VPS, which boots with sane defaults you can then tune, at netbayhosts.in.