Why DNS Works in One Linux Process but Fails in Another

#programming #productivity #beginners #devops

A hostname can resolve in your terminal and still fail inside an application. That does not necessarily mean the DNS server is down: different programs can use different lookup paths, cached answers, network namespaces, or resolver configuration.

Before changing /etc/resolv.conf, identify which layer is failing. This workflow helps distinguish a DNS-record problem from a Linux name-service issue or an isolated container configuration.

Start with the exact name and error

Use the same fully qualified hostname your application uses, including any subdomain. Check whether the failure is about resolving a name or connecting to the resulting address:

getent ahosts api.example.net

getent uses the system’s configured name-service switch, so it is a useful first test for applications that rely on standard system lookups. If it prints addresses, the system resolver path succeeded for this process. It does not prove that a remote port is reachable or that every application uses the same resolver path.

For comparison, query a DNS server directly with dig if it is installed:

dig api.example.net A

The results answer different questions. getent follows the host’s Name Service Switch configuration; dig sends a DNS query. A successful dig alongside a failed getent points toward the local name-service configuration or lookup path, not necessarily the DNS record itself.

If you need to check the host’s interface or routes before investigating further, the ip command guide covers useful address and route checks.

Check how this machine resolves names

Linux commonly uses the Name Service Switch configuration in /etc/nsswitch.conf. Inspect its hosts: line:

grep '^hosts:' /etc/nsswitch.conf

A typical line might include files and dns, or a resolve module. The order matters: the system may consult /etc/hosts, a local resolver service, DNS, or other configured sources. Don’t replace this line with a guessed value; distributions and local setups differ.

Next, inspect resolver configuration and active services:

cat /etc/resolv.conf
resolvectl status

resolvectl is available on systems using systemd-resolved; it may not be installed or active on every distribution. /etc/resolv.conf may also be a symlink managed by NetworkManager, systemd-resolved, or another network service. Check before editing it:

ls -l /etc/resolv.conf

If it points to a generated file, a manual edit may be overwritten. Configure the component that owns the resolver settings instead.

For a hostname that fails only on one machine, compare the relevant resolver settings with a working machine on the same network. Look for differences in DNS servers, search domains, VPN state, and /etc/hosts entries. A short name such as api may resolve only because a search domain is configured; testing api.example.net separately can reveal that distinction.

Separate DNS from connectivity

If name lookup returns an address, test the service separately. For an HTTPS endpoint, for example:

curl -v --connect-timeout 5 https://api.example.net/

The verbose output can show whether the client resolved an address and where the connection failed. A DNS answer does not guarantee that the service is listening, that a firewall allows traffic, or that TLS validation will succeed.

To test a known address without changing DNS, use curl’s --resolve option:

curl --resolve api.example.net:443:203.0.113.25 \
  https://api.example.net/

Replace the example address with an address you have independently verified. This keeps the hostname in the URL—important for HTTP virtual hosting and TLS SNI—while directing this request to the supplied address. If this works while ordinary lookup fails, focus on resolution. If it fails too, inspect the connection, server, and TLS layers.

Avoid treating a successful ping as proof that the application’s DNS or service path works. ICMP may be blocked, and ping does not test the application’s TCP port or TLS behavior.

When only a container or service fails

Containers often have their own resolver configuration and network namespace. Compare the host and container rather than assuming they share the same DNS path.

For a running Docker container, inspect its resolver file:

docker exec app cat /etc/resolv.conf

Then test from inside the container using tools that are actually installed there. Minimal images may not include getent, dig, or a shell. If available, compare the same hostname with getent and dig; do not install packages into a production container just to run a quick test unless that is part of your normal process.

A container’s /etc/resolv.conf may list a Docker-provided resolver address. That can be expected: Docker can forward queries to upstream DNS servers. If lookups fail only in one container, check its network attachment, Compose network settings, and whether a custom DNS setting was applied. Also verify that the hostname is appropriate for that network: a Compose service name is generally useful to containers on the same Compose network, not automatically to the host or the public internet.

For a systemd service, compare the service’s execution environment with your interactive shell. Sandboxing or namespace settings can alter what files or network resources a process can access. If the service is in a container, troubleshoot the container first; if it runs directly on the host, inspect its unit configuration before changing global DNS settings. The systemctl status guide can help you identify the unit state and recent failure details.

Use packet capture only after narrowing the scope

If the resolver configuration looks right but queries time out, a packet capture can show whether DNS traffic leaves the machine and whether replies return. On a system with tcpdump, capture DNS traffic on the relevant interface:

sudo tcpdump -ni any 'port 53'

This filter shows conventional DNS traffic over UDP or TCP port 53. It will not reveal queries sent over encrypted DNS protocols such as DNS over HTTPS, and seeing a query leave does not establish that the response is valid. Use the capture to answer a narrow question: is the process sending a query, and does a response come back?

If the issue is specifically an SSH alias, remember that SSH configuration can introduce another layer: a configured alias may not be the hostname you think it is. The SSH hostname resolution troubleshooting guide explains how to distinguish DNS failures from typos, hosts-file entries, and SSH config aliases.

A practical decision path

When resolution fails, work through these checks in order:

Run getent ahosts for the exact fully qualified name.
Compare with dig to separate system lookup behavior from a direct DNS query.
Inspect /etc/nsswitch.conf, /etc/resolv.conf, and the resolver service that owns them.
If the name resolves, test the application connection separately with curl or the relevant client.
If only a container or service fails, inspect its resolver configuration and network context.
Capture DNS traffic only when you need to establish whether queries and replies are crossing the network.

The key is to test from the same environment as the failing application. A successful lookup in your shell is useful evidence, but it is not proof that a container, service, or library follows the same path.

I'm building SSHFlow — an SSH client that organizes terminals, SFTP, code editing, and server tools into workspaces.