Trace Linux Name Resolution from getent to the DNS Answer

ping can fail while dig succeeds, or an application can resolve a name that does not appear in public DNS. That is possible because “name resolution” is a pipeline, not one command. Linux applications commonly use a C-library resolver interface, a Name Service Switch (NSS) policy selects sources, and a local resolver may route DNS queries to different servers per link.

Follow the pipeline from the application outward. Do not begin by replacing /etc/resolv.conf.

1. Reproduce the application-visible answer

getent ahosts example.com
getent hosts example.com

getent uses the configured NSS database, making it closer to what many normal applications receive than a direct DNS-only tool. getaddrinfo() is the common API beneath hostname-to-address lookup and can return IPv4 and IPv6 results according to family, socket, and system configuration 2.

If getent succeeds but one application fails, inspect that application’s proxy, sandbox, runtime, address-family, or built-in resolver behavior. DNS transport may already be healthy.

2. Read the source order

grep '^hosts:' /etc/nsswitch.conf
grep -nE '^[[:space:]]*[^#[:space:]]' /etc/hosts

The lab host reported:

hosts:          files dns

That means local files are consulted before DNS under this host’s NSS policy. Other systems may include resolve, myhostname, mdns, or distribution modules. The glibc manual defines the NSS configuration model and action syntax 1.

A stale /etc/hosts line can therefore override a correct DNS record. Do not delete unfamiliar entries; identify their owner and purpose first.

3. Ask the local resolver what it used

On a system using systemd-resolved:

resolvectl status
resolvectl query example.com

The verified systemd 255 lab reported IPv4 and IPv6 answers on interface ens3, protocol DNS, a 7.4 ms acquisition time, and whether the response was authenticated, local, or encrypted. Exact addresses and cache state are expected to change.

resolvectl status is especially useful on VPN and multi-interface systems. A single flat nameserver list cannot explain per-link DNS servers, search domains, or routing domains. resolvectl documents those link-aware views 3.

If the command says the service is unavailable, establish which resolver the distribution uses before installing or enabling another one.

4. Query the configured recursive resolver

dig example.com A
dig example.com AAAA
dig +noall +answer example.com A

The compact lab answer included two A records and their remaining TTL:

example.com.  171  IN  A  104.20.23.154
example.com.  171  IN  A  172.66.147.243

Those addresses and TTL have already begun aging; they are evidence from one query, not values to hard-code. dig is a DNS diagnostic client with explicit server, type, transport, and output controls 4. Without @server, this query uses the configured recursive resolver; it is not an authoritative- server query.

Ask a particular server only when that comparison is relevant:

dig @192.0.2.53 service.internal.example A

Replace the documentation address with an approved resolver. Sending a private name to a public resolver can leak internal naming information and may produce a misleading NXDOMAIN because split DNS intentionally answers only on the VPN.

5. Compare layers, not just success

Also separate resolution from reachability:

getent ahosts service.example
ip route get 192.0.2.10

Use an address actually returned in your environment. A valid record does not prove a route, open port, TLS identity, or healthy application.

6. Capture a useful incident record

Record the timestamp, hostname, active interface/VPN, hosts: NSS line, application-visible getent result, resolvectl query result, and an explicit dig server when used. Redact private names and addresses before sharing.

That sequence locates the disagreement without flushing caches or rewriting configuration. First ask what the application sees, then why NSS chose it, then which resolver answered, and only then compare raw DNS.