Dennis HilkLinux Fix LabDE

Networking, DNS & Wi-Fi

Address connectivity works but DNS resolution fails

Inspect systemd-resolved’s upstream servers and resolv.conf integration when names fail, including DNS loops and validation errors without disabling safeguards.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • A known service remains reachable by its confirmed IP but its hostname fails.
  • resolvectl reports missing name servers, a resolver loop or DNSSEC validation failure.

Relevant environment

Systems intentionally using systemd-resolved, often integrated with NetworkManager; other resolver managers need their own documented configuration.

Recognizable messages (synthetic examples)
intranet.example: resolve call failed: No appropriate name servers or networks for name found

Inspect per-link DNS and domain routing; do not interpret this as an authoritative nonexistent-name response.

intranet.example: resolve call failed: Configured DNS server loops back to us

Check for the local stub address being supplied as upstream DNS or a loop between local forwarding resolvers.

systemd-resolved[720]: DNSSEC validation failed for question signed.example IN A: signature-expired

Check time, the domain’s signing chain and upstream behavior before changing validation policy.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • Per-link DNS can be absent or assigned to the wrong link, while /etc/resolv.conf may point to a stale file or inactive local stub.
  • A local DNS stub configured as its own upstream creates a loop; DNSSEC failures instead require time, signing and upstream evidence.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read global and per-link DNS servers, domains and default-route policy without changing them. If the service is unavailable, confirm whether this system is meant to use resolved.

resolvectl status

Interpret the result: 127.0.0.53 is normally the local client stub, not an upstream DNS server for resolved. A correct per-link server still needs an IP route and may intentionally serve only a domain.

Check 2

Resolve the file’s path without editing it. A plain file can be a valid mode; compare the result with the distribution’s intended resolver integration.

readlink -f /etc/resolv.conf

Interpret the result: A stub-resolv.conf target expects the local stub to be available. The upstream resolv.conf mode bypasses stub-specific per-link routing for clients that read it directly; neither mode should be forced without checking the design.

Check 3

Replace HOSTNAME with a known hostname you are authorized to query. This sends a DNS query but does not alter configuration; avoid sharing private names in pasted output.

resolvectl query HOSTNAME

Interpret the result: No appropriate name servers is a routing/server-selection failure, not proof that the name does not exist. DNSSEC validation failed is distinct from NXDOMAIN and warrants the detailed resolver log.

Evidence-guided next steps

Restore the intended local resolver integration

If the system is designed for resolved but /etc/resolv.conf or NetworkManager’s DNS plugin no longer matches that design, save the file/symlink and configure the documented distribution integration. Restore the local stub service only when that selected mode requires it.

Precautions: Preserve VPN domain routing and any intentional alternative resolver. Do not make resolv.conf immutable or replace all DNS servers with a public server that cannot resolve internal names.

Recovery / rollback: Restore the saved resolv.conf form and previous DNS plugin/service state, then reconnect the affected profile if DNS becomes worse.

Did this solution help you?

Share this solution#

Correct the confirmed upstream or loop

If resolved lacks the intended per-link DNS or lists its own stub as upstream, correct that connection’s DNS source to the server supplied by the network administrator or valid DHCP configuration. Keep route-only domains attached to their intended link and compare the same hostname.

Precautions: The DNS server must be reachable through its intended network. Changing only a server address cannot repair a disconnected VPN or missing IP route.

Recovery / rollback: Restore the saved per-link DNS addresses, domain list and ignore-auto-dns setting; reactivate the previous profile if necessary.

Did this solution help you?

Share this solution#

Resolve a DNSSEC validation failure

If the resolver reports DNSSEC failure, check actual system time and the detailed failure reason before changing DNS policy. Correct verified clock drift through the intended time service; if only one signed domain fails, have its administrator inspect the signature/trust chain or a filtering upstream.

Precautions: Do not globally disable DNSSEC to hide an unexplained validation failure. Large time changes can affect certificates and active sessions, so use the normal time-sync recovery procedure.

Recovery / rollback: Restore any saved DNS server or time-service configuration if that comparison regresses; keep validation policy intact while the authoritative problem is investigated.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.