Asciiroot Systems

Linux troubleshooting guide

Linux DNS resolution failure: a safe troubleshooting guide

Name-resolution failures can originate in application settings, local name-service configuration, a resolver, the network path or the authoritative DNS data. Separate these possibilities before changing records.

Before you begin: The getent example uses Linux name-service facilities and may make a network query. resolvectl applies only where systemd-resolved is installed and active. These examples are not executed or verified against your system. Obtain authorization, protect sensitive output and involve the responsible owner.

Clarify the incident

Collect the relevant scope and timeline before choosing an action:

  • Which name and record type fail, what is the exact error, and which clients or applications are affected?
  • Does the issue occur for one name or all names, and does it happen from another authorized client?
  • Which name-service path and upstream resolvers does the affected application actually use?

Possible explanations

These are alternatives to investigate, not confirmed causes:

  • Local name-service settings, resolver availability or a network path may affect lookups; verify each separately.
  • An absent or incorrect record, cache, delegation or upstream response can produce a similar symptom.

Read-only checks

Replace example names and paths only after confirming the applicable platform, permissions and change policy. Command output can contain sensitive data.

Linux with glibc: name-service lookup

Replace example.com with an authorized name; the lookup can contact a resolver and may use hosts files or caches. If it succeeds but the application fails, compare the application’s resolver path; if it fails, inspect that path and the authoritative answer.

getent ahosts example.com

Linux with systemd-resolved: resolver status

Use only where systemd-resolved is installed and active. Compare the configured resolver and per-link domains with the affected lookup; review addresses locally before sharing.

resolvectl status

Interpret the evidence

The name-service lookup succeeds

The application can still use a different resolver, network namespace or cache. Compare the path used by the affected application rather than assuming DNS is healthy everywhere.

The lookup fails or times out

Distinguish a missing name from a timeout, then inspect the configured resolver, approved network path and authoritative response. A timeout does not establish that a record is absent.

Different clients get different results

Compare resolver settings, caches, record type and TTL. getent address lookups are not an MX-record test; use a suitable DNS tool for the specific record type when authorized.

Plan recovery and verification

  1. Confirm scope: Identify the affected names, record types, clients, error and time without changing DNS.
  2. Collect evidence: Compare the application name-service path, local resolver status, authoritative answer and relevant network reachability.
  3. Prepare rollback: Record existing settings, ownership and recovery access before an approved DNS or resolver change.
  4. Apply an approved correction: Change only the verified configuration or record through the responsible DNS owner; account for caching and TTLs.
  5. Verify and monitor: Recheck the affected clients and applications, compare authoritative and cached answers, and monitor recurrence.

Watch for recurrence: After an approved correction, test the affected application and representative authorized clients over time. If failures return, compare resolver availability, network reachability, record answers and cache behavior.

Documentation pointers

Check the documentation for your product and installed version. These links are references, not live verification.

Explore a safe demonstration

The scenario lab illustrates a fixed example. It does not reproduce this incident or verify a production fix, and it never executes your commands.

Open the related scenario lab

Related Linux guides