How to Fix DNS Issues: A Playbook for SREs and DevOps

A service is timing out, dashboards are red, and half the team is arguing about whether the app is broken or the network is. Meanwhile, users just see “host not found” and retries are piling up. This is the point where “it's always DNS” stops being a joke and starts being an incident command problem.

Most DNS guides split the world in two. One tells you to flush a laptop cache. Another dives straight into zone files and recursive resolvers. Real incidents don't respect that split. You need one playbook that starts with the fastest checks, moves into protocol-level evidence, and ends with system-wide correlation when the issue is intermittent or noisy.

Table of Contents

• When It Is Always DNS You Need a Plan
• Initial Triage The First 5 Minutes
  • Use a public resolver as a diagnostic control
• Diagnostic Deep Dive with Dig and Nslookup
  • Ask the same question in different ways
  • Read the failure mode, not just the answer
  • Dig vs. Nslookup Quick Reference
• Server-Side vs Client-Side Root Cause Analysis
  • Decide where the failure lives
  • What broken delegation looks like in practice
  • Use packet capture when the tools disagree
• Correlating DNS Errors with Logs in Fluxtail
  • CLI tools show a host, logs show a fleet
  • What to search for during a live incident
• Building a Resilient DNS Strategy
  • Design for failure before the next incident
  • Operational habits that reduce blast radius

When It Is Always DNS You Need a Plan

The common failure pattern is messy. One service can still reach upstream APIs by IP, but fails by hostname. A browser works on one machine and not another. Internal health checks flap while infrastructure graphs look fine. That combination wastes time because people chase the wrong layer.

DNS is resilient right up until one part of the chain gets stale, misrouted, intercepted, or delegated incorrectly. Then symptoms scatter everywhere. The frontend team sees connection failures. Platform engineers see retries. The network team sees packets. Nobody sees the whole chain unless someone forces the investigation into a sequence.

That sequence matters more than raw expertise under pressure.

Practical rule: Don't start by editing records, swapping resolvers, or restarting services at random. First prove whether the host has connectivity, whether the resolver path works, and whether the authority chain is intact.

The runbook I trust starts with triage that gives immediate signal. Then it pivots into targeted queries with dig, nslookup, or Resolve-DnsName. If the problem appears wider than one host, I stop treating it as a workstation issue and start looking for resolver policy, broken delegation, or application-level behavior like proxying, secure DNS, or sidecar interception.

Three questions narrow the search fast:

• Is basic network connectivity intact: If raw IP connectivity is broken, DNS is only a symptom.
• Does resolution fail everywhere or only from one path: That tells you whether to focus on client state or shared infrastructure.
• Do authoritative answers match what recursive resolvers return: If they don't, you're dealing with propagation, caching, policy, or delegation trouble.

Experienced responders don't “know” it's DNS. They prove it quickly, then isolate which DNS problem they have. That's how to fix DNS issues without turning a recoverable outage into a longer one.

Initial Triage The First 5 Minutes

An alert fires. Users report "server not found." One service is down from laptops on Wi-Fi, but healthy from a pod in the cluster. Those first five minutes decide whether this stays a short incident or turns into a noisy hour of random fixes.

The goal is simple. Separate client-path failure from shared DNS failure before anyone edits records or restarts production services.

Paessler's DNS troubleshooting guide outlines a practical order for early checks. I use a similar sequence because each step removes a full class of causes quickly, and because it works across workstation, branch-office, and server incidents.

1. Verify raw connectivity first. If ping 8.8.8.8 fails, stop treating this as DNS. You have a reachability problem, a firewall issue, or a broken route.
2. Flush the local resolver cache. Use ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS, or systemd-resolve --flush-caches on Linux. This clears stale answers that can keep one host broken after the rest of the fleet has recovered.
3. Confirm which DNS servers the host is using. ipconfig /all, resolvectl status, or /etc/resolv.conf gives the answer fast. If the host points at the wrong resolver, every later test sends you in the wrong direction.
4. Remove interceptors from the path. VPNs, proxies, browser secure DNS, endpoint security agents, and service meshes can alter DNS behavior. Disable them one at a time and retest. Under pressure, this catches more false leads than people expect.
5. Check the local DNS client and the failing app. A broken stub resolver, dead local caching service, or app-specific proxy setting can look identical to upstream DNS failure from the user's point of view.

Run those checks on one affected host first. Then compare with one known-good host on the same network if you have one. That gives you a control case without introducing too many variables.

Teams that shorten this phase usually shorten the whole incident. That is the point behind improving mean time to resolution during operational incidents.

Use a public resolver as a diagnostic control

Query the same failing name through the default resolver and through a public resolver such as 1.1.1.1 or 8.8.8.8. Treat it as an A/B test, not as a permanent fix.

If the public resolver returns the expected answer and the default resolver does not, focus on the ISP resolver, internal forwarding tier, split-horizon policy, or filtering on the local path. If both fail, look harder at the authoritative side, delegation, propagation, client policy, or the application itself.

Keep the test disciplined. One host. One failing name. One alternate resolver.

Later in the triage, a video walkthrough can help if you're coaching a less experienced responder through the sequence.

Diagnostic Deep Dive with Dig and Nslookup

Once fast triage says “this really is DNS,” stop guessing and interrogate the protocol directly. dig is usually the cleaner instrument for this. nslookup is still useful, especially when you need a quick check on systems where it's already available. The point isn't tool loyalty. The point is asking precise questions and comparing answers from different parts of the chain.

Ask the same question in different ways

Start by querying the failing name for the record type you expect. Then ask a different resolver the same question. Then ask for adjacent records that change the meaning of the response.

For example, if an application can't connect to a service name, don't stop at the first address lookup. Check whether the name is a CNAME, whether the nameserver set looks right, and whether TXT records reveal provider-managed validation or policy clues. The fastest path to truth is comparison:

• Query the expected record type: A for IPv4, CNAME for aliases, NS for authority, TXT when provider configuration matters.
• Query a specific resolver directly: Compare your default resolver against a public resolver.
• Trace the chain: dig +trace shows where the handoff breaks between root, TLD, and authoritative nameserver layers.

This is also where using public resolvers becomes a deliberate diagnostic move, not just a fallback. Manually switching to public resolvers such as Google Public DNS or Cloudflare resolves the majority of persistent DNS failures caused by ISP-specific degradation or misconfiguration, as noted in Lenovo's DNS issues overview. In practice, that tells you whether your default recursive layer is the culprit.

A resolver that answers differently from another resolver isn't “weird.” It's evidence. Treat it that way.

Read the failure mode, not just the answer

DNS errors are informative if you don't flatten them into “lookup failed.”

NXDOMAIN usually means the queried name doesn't exist from the resolver's point of view. That can mean a typo, a missing record, or a search-suffix problem on the client. SERVFAIL is more interesting. It often points to upstream failure, broken delegation, DNSSEC trouble, or an authoritative server that can't complete the answer chain. REFUSED tells you the server heard you and declined to answer, which pushes the investigation toward policy, ACLs, split-horizon rules, or resolver restrictions.

When dig +trace dies before reaching authority, the delegation path is suspect. When direct queries to authority succeed but recursive queries fail, suspect recursion policy, forwarders, or cached bad state. When one application fails but CLI lookups succeed, suspect the app runtime, browser secure DNS behavior, proxy rules, or local policy.

Dig vs. Nslookup Quick Reference

One practical caveat on Windows. nslookup doesn't always reflect the same name resolution path that Windows applications use. If you're troubleshooting a Windows-specific client symptom, Resolve-DnsName can be a better reality check because it aligns more closely with the platform resolver behavior. Even then, I still like comparing outputs across tools because disagreements are useful clues.

If you're trying to learn how to fix DNS issues under pressure, this is the part that separates protocol evidence from intuition. Ask a narrower question. Compare answers from multiple vantage points. Let the response codes tell you which layer to inspect next.

Server-Side vs Client-Side Root Cause Analysis

At this stage, the investigation needs a hard pivot. Either the client path is lying to you, or the server side is broken for everyone. Mixing those two buckets slows incidents down because the fixes are completely different.

Decide where the failure lives

Start with a simple question: can other clients resolve the same name from different networks or subnets?

If the answer is yes, the shared DNS infrastructure is probably fine and the affected host deserves scrutiny. Flush local state, inspect adapter settings, check for application-level overrides, and look for policy engines that intercept name resolution. Browsers, service meshes, VPN agents, and endpoint protection products can all create a gap between “DNS works on this machine” and “this app still can't resolve.”

If the answer is no, stop treating it like a laptop problem. Move to the shared path:

• Check resolver health: Is the recursive service running and responding consistently?
• Verify the zone data: Are the expected records present and current?
• Inspect reachability: Can clients reach the resolver, and can the resolver reach authority?
• Compare authoritative and recursive answers: Mismatch means caching, policy, or delegation.

When multiple clients fail in the same way, local cache flushing becomes noise. Shift to shared components immediately.

What broken delegation looks like in practice

One of the most damaging server-side issues is broken delegation. Microsoft's enterprise DNS guidance is very specific here: if an NS record exists without a valid corresponding A record IP, the zone has a broken delegation, which is a primary cause of recursive resolution failures, as documented in Microsoft's DNS server troubleshooting guide.

This problem is easy to miss because parts of DNS can still appear healthy. You may see nameserver records in the parent zone and assume delegation is fine. It isn't fine if the resolver can't turn those nameserver names into usable addresses. In that case, recursion breaks even though the zone “looks configured.”

A practical enterprise workflow looks like this:

1. Confirm network stack parameters. ipconfig /all tells you what resolver path and suffix state the host has.
2. Query the delegated nameservers directly. Use dig or nslookup against each delegated server.
3. Inspect whether NS targets have matching address records. If they don't, the parent zone needs correction.
4. Fix the parent-side glue or address mapping. Local client fixes won't solve a broken delegation.

This is the kind of failure that survives cache flushes, app restarts, and workstation swaps. It only disappears when authoritative configuration is repaired.

Use packet capture when the tools disagree

Sometimes command output is too polite. The host says “temporary failure in name resolution,” dig works when forced to a public resolver, and the app still fails. That's when packet capture earns its place.

Use tcpdump on port 53 to see whether queries leave the host, where they go, and what comes back. You're looking for facts, not interpretations:

• No outbound queries: The application may be using a different path, local stub, proxy, or policy engine.
• Queries leave but no responses return: Suspect firewall rules, upstream reachability, or dropped fragments.
• Responses return with unexpected codes: Now you have protocol-level proof of recursion, policy, or authority issues.
• The app never asks for the name you expected: The bug may be in config, suffix handling, or application logic.

Packet capture also helps when caching muddies the water. If you don't trust what the resolver library says, trust the wire.

Client-side and server-side analysis shouldn't be treated as separate disciplines. In incidents, they're one chain. The skill is knowing where to cut into it.

Correlating DNS Errors with Logs in Fluxtail

A single-host shell session is great for proving what one machine sees. It's weak when the failure is intermittent, isolated to one service tier, or triggered by a rollout. DNS incidents often look random until you line up application logs, infrastructure logs, and deployment timing in one place.

CLI tools show a host, logs show a fleet

When an API gateway starts logging EAI_AGAIN, worker nodes emit “unknown host,” and one backend reports “name resolution timed out,” that's no longer a workstation puzzle. It's a pattern. Centralized logs let you see whether the problem is tied to a stream, host group, deployment window, or service dependency.

That changes how you respond. Instead of asking one machine whether DNS is broken, you ask the whole system where resolution failed first and who was affected next. During a production incident, that's often the difference between isolated debugging and coordinated response.

A strong habit is to pair protocol tests with readable log evidence. Teams that want a cleaner workflow for parsing incident output should get sharper at reading logs effectively during investigations.

What to search for during a live incident

During a DNS event, search broadly first and narrow second. Look for exact failure strings across application and system logs, then split by service or host to find the blast radius.

Useful search patterns include:

• Application resolver failures: EAI_AGAIN, getaddrinfo, unknown host
• Timeout language: name resolution timed out, temporary failure in name resolution
• Container and runtime clues: startup failures that mention dependency hostnames
• Deployment correlation: config reloads, sidecar updates, service mesh changes, or network policy pushes

Then switch from search to comparison.

A good incident sequence looks like this:

Logs won't tell you how DNS works. They will tell you when the system started failing, which components failed together, and whether your fix actually changed behavior.

For intermittent DNS trouble, centralized correlation beats repetitive shell commands every time. You still need dig, nslookup, and packet capture. But when the incident spans multiple services, logs turn scattered symptoms into a timeline you can act on.

Building a Resilient DNS Strategy

At 2 a.m., DNS strategy stops being an architecture diagram and becomes a business continuity problem. If a branch office loses name resolution, a VPN appliance keeps forwarding to a dead resolver, or a bad record gets cached across half the fleet, the team that recovers fastest is usually the team that designed for partial failure ahead of time.

Design for failure before the next incident

Start with resolver paths and failure domains.

One DNS server is a single point of failure. One provider can be a single control-plane failure. One region can be enough to break resolution for a whole application if every client follows the same path. Split those risks on purpose.

A practical baseline looks like this:

• Use more than one resolver path. Pair local resolvers with upstream diversity, or use separate providers for critical workloads.
• Spread infrastructure across regions or sites. This helps when a network path degrades even though the resolver itself is still healthy.
• Avoid provider monoculture for business-critical zones. Diversity matters more for DNS than teams expect because control-plane mistakes replicate fast.
• Set TTLs based on recovery needs, not habit. Long TTLs cut query load and shield authoritative servers. They also slow rollbacks and keep bad answers alive longer.

Dual-stack environments need extra scrutiny because IPv4 and IPv6 resolution paths do not always fail the same way. Teams reviewing resolver design or migration plans should understand how IPv6 DNS server behavior affects resolver reliability and operations.

Operational habits that reduce blast radius

Resilient DNS is mostly disciplined routine work.

The teams that handle incidents well usually do the same things before the incident: they test from multiple vantage points, audit records before changes, and verify delegation instead of assuming the registrar and authoritative provider stayed aligned.

Use a runbook that covers both client-side and server-side checks:

1. Monitor actual resolution, not just daemon health. Query expected records from office networks, production nodes, and remote-user paths.
2. Audit records before and after changes. Check A, AAAA, CNAME, MX, NS, and TXT records, especially after migrations or CDN changes.
3. Verify delegation end to end. Parent-zone NS records, glue records, and child-zone answers all need to match.
4. Practice resolver failover. If the plan says "switch upstreams" or "promote secondary," test it before an outage.
5. Keep runbooks short and executable. During an incident, responders need exact commands, expected outputs, and rollback criteria.

Edge networks deserve their own playbook. In branch offices, retail sites, and home-office setups, router and gateway DNS state fails in boring ways: stale forwarders, wedged caches, or broken WAN reconnection after an ISP flap. Restarting the router is still a valid operational step in those environments. It is not a substitute for sound design, but it often clears bad local state faster than trying to debug a consumer-grade device under pressure.

The main shift is procedural. Teams that fix DNS quickly treat it as one incident stream, not two separate subjects called "client issue" and "server issue." They check the endpoint, the recursive layer, the authority chain, and the logs in one sequence. That is how you cut mean time to recovery and avoid repeating the same outage six weeks later.

When DNS incidents get messy, readable centralized logs make the difference between chasing one bad host and seeing the whole failure pattern. Fluxtail gives engineering teams live tail, named streams, analytics, alerts, and AI-assisted investigation in one place so you can correlate resolver errors, app failures, and rollout timing without juggling tools.