← Docs
Networking updated July 3, 2026

It's always DNS: diagnosing name resolution failures

Learn how to diagnose and resolve issues with domain name system (DNS) lookups.


It's Always DNS: Diagnosing Name Resolution Failures

When you encounter issues with resolving hostnames, the problem often lies in your Domain Name System (DNS). This document provides a step-by-step guide to diagnosing and resolving these issues.

Why "It's Always DNS" is True

The Domain Name System sits at the heart of every network connection. It translates human-readable domain names into IP addresses. When something goes wrong with DNS, it can cause intermittent or confusing failures that might seem like broader network issues. This document will help you identify and resolve these problems.

Symptoms That Indicate a DNS Issue

  • Ping 1.1.1.1 Works but Ping Google.com Fails: If ping 1.1.1.1 works but ping google.com fails with "could not resolve host," the network is likely fine, and the issue lies in name resolution.
  • Sites Work by IP but Not Name: This indicates that DNS lookups are failing while other parts of the network are functioning correctly.
  • New Tab Fails While an Open App Keeps Working: The application has cached the correct IP address, but a new tab or browser session does not have this cache.

Diagnostic Ladder

  1. Which Resolver Am I Using?

    • Use commands like resolvectl status or ipconfig /all to check your current DNS resolver.
    • Surprising answers here (e.g., an old Pi-hole, a dead VM) can resolve many issues.
  2. Ask the Resolver Directly:

    • Run dig example.com @192.168.1.1 and compare it with dig example.com @1.1.1.1.
    • If your local resolver fails but 1.1.1.1 works, your resolver (e.g., Pi-hole, router) is the problem.
    • Both failing indicates an upstream issue or a problem with the domain itself.
  3. Read the dig Output:

    • NXDOMAIN: The name does not exist (likely due to a typo or incorrect search domain).
    • SERVFAIL: The resolver tried and failed, often due to DNSSEC issues or dead upstream servers.
    • Empty Answer vs No Response: Different diagnostic clues.
  4. Clear Caches:

    • Flush local caches with resolvectl flush-caches or ipconfig /flushdns.
    • Remember that browsers also have their own DNS cache, which can be cleared in the browser settings.
    • TTLs (Time to Live) mean changes may not propagate immediately.

Homelab-Specific Gotchas

  • DNS Single Point of Failure: Using a single resolver like Pi-hole or AdGuard as your primary DNS can cause issues if it hangs. Consider giving DHCP a secondary resolver.
  • Split-Horizon Surprises: Internal names might resolve to public addresses, while internally you expect LAN addresses.
  • Docker Resolver Chain: Docker containers use their own resolver (127.0.0.11) that ignores the host's /etc/hosts, leading to "works on host, fails in container" issues.

By following this diagnostic ladder and understanding these common gotchas, you can effectively troubleshoot DNS resolution failures in your network.

Was this useful?

This doc is maintained by the humans who run BreadLab. Spotted an error? Tell us — we fix docs, not just typos.