DNS Resolution Troubleshooting

Local connectivity confirmed in Chapter 3 means this machine can reach its gateway and, through it, the rest of the network. The next rung, per Chapter 2's ladder, is DNS: does the name the user is actually typing resolve to the IP address it's supposed to? This chapter covers the two tools that answer that question, the handful of failure patterns that cover almost every real DNS ticket, and one technique — bypassing local DNS entirely — that's often the single fastest way to tell a local infrastructure problem apart from a genuine, global DNS issue.

How Resolution Actually Happens

When a name is looked up, the request doesn't necessarily go out to "the internet" fresh every time. It typically passes through several layers, any of which might already hold — or wrongly hold — an answer: the application's own cache, the operating system's resolver cache, the configured DNS server (often a local corporate resolver), and only then, if nothing already has an answer, a chain of recursive lookups out to the authoritative servers for that domain. Every one of those layers can cache a result for a period of time set by that record's TTL (time to live) — which matters a great deal diagnostically, and gets its own warning later in this chapter.

Two Tools, One Underlying Answer

Reading a Healthy Resolution

Two things worth noting even in a healthy result: which server answered (dns.corp.example.com here — the locally configured resolver, not necessarily the domain's own authoritative server), and that the answer is marked "non-authoritative" — meaning it came from a cache somewhere along the chain, not fresh from the domain's own DNS servers. Neither is a problem on its own; both become relevant the moment the answer looks wrong.

The Four Failure Patterns

The line to look for is always status: — in dig's output it's stated explicitly, which is exactly why it's the more useful tool once you already suspect a DNS problem rather than just doing a routine lookup.

Bypassing Local DNS to Isolate the Problem

One of the most useful single techniques in this chapter: query a known public DNS server directly, instead of whatever's configured by default, and compare the two answers.

Two different answers for the same name is a genuinely strong signal: the local resolver is holding a stale or otherwise incorrect answer, while the public internet's view of that domain is already correct — or, less often, the reverse, if a change was only made locally and hasn't propagated out yet. Either way, this single comparison usually tells you within seconds whether the problem is specific to local DNS infrastructure or a real, global issue with the domain itself.

Working Example: Continuing the Ticket

The ticket from Chapters 1–3 continues: local connectivity confirmed, so the ladder moves to DNS. nslookup app.example.com from the user's machine returns 203.0.113.77 — but a quick dig @8.8.8.8 app.example.com +short from your own machine returns 203.0.113.42, a different address. That mismatch alone is the finding: this user's local DNS resolver is serving a stale answer, most likely a caching issue on the corporate resolver or a TTL that hasn't yet expired since a recent change. The fix belongs to DNS infrastructure, not the application — and the ladder can move to Chapter 5 once a correct answer is confirmed, to check whether the right IP is actually reachable.

Hands-On Exercises