Network / DNSUpdated 2026-09-09About 3 min read · execution time varies

Linux DNS resolution failure: verify resolv.conf through container DNS

Separate missing network reachability, an unavailable resolver, wrong records, and stale application caching before changing DNS settings.

Maintained by Kevin · Ovalk

Scope and prerequisites

Linux with dig and a system resolver; resolver management varies between systemd, NetworkManager and containers.

Use a public example name only when querying public resolvers. Never send private service names to an external DNS server. Collect results from the same namespace as the failing application.

Examples are not commands to paste blindly. Replace example domains, paths, service names and UPPERCASE placeholders. Gather evidence first; reloads, rollbacks, prune operations and job executions change state and require an approved impact and recovery plan. Never share credentials or unredacted logs.

Common symptoms

curl reports Could not resolve host.
A name resolves on the host but not in a container.
NXDOMAIN or timeout failures are intermittent.

1. Test each resolver path

Query the system default resolver and a specified server independently. If the specified server fails, investigate network or firewall access; if only default fails, inspect resolv.conf, systemd-resolved, or container DNS.

cat /etc/resolv.conf
dig example.com
dig @1.1.1.1 example.com +short

2. Inspect search domains and runtime behavior

Short names depend on search domains, ndots, and language libraries. In Kubernetes also inspect Pod DNS policy, CoreDNS, and the namespace-qualified service name.

getent hosts example.com
resolvectl status 2>/dev/null || true

3. Preserve evidence before changing resolvers

Record name, time, resolver, response code, and source network. Public DNS is not necessarily a safe replacement for an internal split-horizon resolver.

journalctl -u systemd-resolved --since "1 hour ago" --no-pager

Interpret the evidence

Observation	What to check next
NXDOMAIN	The queried name does not exist in this resolver’s view. Check spelling, search suffix, authoritative records and cached negative answers.
SERVFAIL or timeout	SERVFAIL is a failed resolution, not proof of a missing record. A timeout has no usable reply; inspect upstream health and UDP/TCP DNS reachability.
dig works; application fails	Compare getent and the application’s resolver/cache behavior. A raw DNS answer does not test hosts-file or NSS rules.

Illustrative diagnosis

A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.

An application container cannot resolve an internal database, while the host can. A public website resolves in both places. This isolates the failure to the private-name path, not general connectivity. Compare container DNS configuration and search suffixes with the intended private resolver; switching everything to public DNS would make the private database permanently unreachable.

Verify recovery

Resolve the exact fully qualified name from each affected runtime, then test the application connection—not only an IP lookup.
Repeat after the relevant positive or negative cache TTL and ensure the answer matches the intended private/public view.

Rollback and stopping point

Record the resolver configuration and its owning service before changes. Restore it through that service if private names or other workloads fail. Do not hand-edit generated resolv.conf as a lasting fix.

Prevention and long-term repair

Probe critical A, AAAA, and CNAME records with latency.
Document internal and external split-horizon rules.
Test resolver behavior in node, container, and application runtime paths.

References and corrections

Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.

BIND dig reference

Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.