{"id":27,"date":"2026-07-30T16:50:39","date_gmt":"2026-07-30T13:50:39","guid":{"rendered":"https:\/\/john-nessime.com\/blog\/?p=27"},"modified":"2026-07-30T16:50:42","modified_gmt":"2026-07-30T13:50:42","slug":"dns-troubleshooting","status":"publish","type":"post","link":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/","title":{"rendered":"DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours"},"content":{"rendered":"\n\n<p class=\"wp-block-paragraph\">Someone messages you: &#8220;the site is down.&#8221; You open it \u2014 it loads fine on your machine. You ask them to try again, and it still fails. Nothing changed on the server. Nothing changed in the code. And somewhere in the back of your head a small voice says: <em>it&#8217;s DNS again.<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It usually is. Not because DNS is fragile, but because it&#8217;s the one layer where caching, delegation, and propagation all conspire to make the same domain behave differently depending on who&#8217;s asking and when. A record can be perfectly correct in your control panel and still resolve to the wrong IP for half the internet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This article is the DNS troubleshooting workflow I actually use \u2014 the order of checks, the commands worth memorising, how to read what they tell you, and the specific failure patterns that show up over and over. No theory dumps. Just the path from &#8220;something&#8217;s broken&#8221; to &#8220;here&#8217;s exactly which record on which server is wrong.&#8221;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">First, Get the Mental Model Right<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">You can&#8217;t debug a system you don&#8217;t have a picture of. When a browser resolves <code>example.com<\/code>, several independent parties are involved, and any one of them can be the liar:<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li><strong>The application<\/strong> \u2014 browsers keep their own short-lived DNS cache, and HSTS or connection pooling can mask changes entirely.<\/li><li><strong>The operating system<\/strong> \u2014 the local stub resolver, <code>\/etc\/hosts<\/code>, <code>nscd<\/code>, <code>systemd-resolved<\/code>, or the Windows DNS Client service.<\/li><li><strong>The recursive resolver<\/strong> \u2014 your router, your ISP, or a public resolver like 1.1.1.1 or 8.8.8.8. This is where most stale answers live.<\/li><li><strong>The delegation chain<\/strong> \u2014 root servers, then the TLD servers, then whichever name servers your registrar says are authoritative.<\/li><li><strong>The authoritative name server<\/strong> \u2014 the only place where the truth actually lives.<\/li><\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Effective DNS troubleshooting is just working down that list and asking each party the same question directly, instead of trusting whatever the browser tells you. The moment you find two parties giving different answers, you&#8217;ve found your boundary \u2014 and the problem is between them.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The Tools That Matter<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">You need surprisingly few. My honest ranking:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">dig \u2014 the one you should learn properly<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>dig<\/code> is the only tool that shows you everything: the query it sent, the response status, the TTL remaining, the authority section, and whether the answer came from a cache or from the source. On Debian and Ubuntu it lives in <code>dnsutils<\/code>; on RHEL-family systems it&#8217;s in <code>bind-utils<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Just the answer, nothing else\ndig +short example.com A\n\n# The full picture \u2014 status, flags, TTL, authority\ndig example.com A\n\n# Ask one specific resolver instead of the system default\ndig @1.1.1.1 example.com A\n\n# Ask a specific authoritative server directly\ndig @ns1.example-dns.com example.com A<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">host \u2014 for quick sanity checks<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>host example.com\nhost -t MX example.com\nhost -t TXT example.com<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">nslookup \u2014 fine, but know its limits<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>nslookup<\/code> is everywhere, including Windows, which is its main virtue. But it hides details you often need, and its &#8220;Non-authoritative answer&#8221; banner confuses people constantly \u2014 it simply means the answer came from a cache rather than the authoritative server. That&#8217;s completely normal. On Windows I reach for PowerShell instead:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Resolve-DnsName example.com -Type A\nResolve-DnsName example.com -Server 1.1.1.1<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">resolvectl \u2014 essential on modern Linux<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If the machine runs <code>systemd-resolved<\/code>, your <code>\/etc\/resolv.conf<\/code> probably points at <code>127.0.0.53<\/code>, which tells you nothing about the real upstream servers. <code>resolvectl<\/code> does:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>resolvectl status\nresolvectl query example.com\nresolvectl statistics<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">getent \u2014 the reality check<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>dig<\/code> talks to DNS. Your applications talk to the C library resolver, which also consults <code>\/etc\/hosts<\/code> and whatever else <code>\/etc\/nsswitch.conf<\/code> lists. When <code>dig<\/code> and the application disagree, this is the command that explains why:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>getent hosts example.com\ngetent ahosts example.com<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">A Repeatable DNS Troubleshooting Workflow<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is the sequence. Don&#8217;t skip ahead \u2014 each step eliminates a whole class of causes, and jumping straight to the authoritative server is how you spend an hour fixing something that was never broken.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1 \u2014 Confirm it&#8217;s actually DNS<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Resolve the name, then connect to the resulting IP directly. If the IP works and the name doesn&#8217;t, it&#8217;s DNS. If neither works, you&#8217;re troubleshooting the wrong layer.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dig +short example.com A\ncurl -I --resolve example.com:443:203.0.113.10 https:\/\/example.com\/<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The <code>--resolve<\/code> flag is underrated. It forces curl to use an IP you specify while still sending the correct Host header and SNI, which lets you test the web server as if DNS were already fixed. Replace <code>203.0.113.10<\/code> with the IP you expect.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2 \u2014 Compare local vs public resolvers<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>dig +short example.com A\ndig +short @1.1.1.1 example.com A\ndig +short @8.8.8.8 example.com A\ndig +short @9.9.9.9 example.com A<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If your local answer differs from all three public resolvers, the problem is on your side \u2014 a cache, a hosts file entry, a VPN pushing internal DNS, or a router doing something creative. If all four agree but the answer is wrong, the problem is upstream at the authoritative layer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3 \u2014 Find out who is actually authoritative<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This is the step people skip, and it&#8217;s the one that catches the nastiest problems. The name servers listed in your DNS provider&#8217;s dashboard are not necessarily the ones the internet is using.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># What the parent zone (the registry) says\ndig +short NS example.com\n\n# What the zone itself says, straight from one of those servers\ndig @ns1.example-dns.com example.com NS<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Those two lists should match. When they don&#8217;t, you&#8217;ve usually found a half-finished DNS migration: the registrar still delegates to the old provider, so the world keeps reading a zone nobody has updated in months.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4 \u2014 Query every authoritative server individually<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A zone with four name servers can be inconsistent across them if a zone transfer failed. Intermittent, &#8220;it works every third time&#8221; problems are almost always this. Compare the SOA serial on each:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Pull the SOA record from every authoritative server in one shot\ndig +nssearch example.com\n\n# Or check them one by one\ndig +short @ns1.example-dns.com example.com SOA\ndig +short @ns2.example-dns.com example.com SOA<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Different serial numbers mean the secondaries haven&#8217;t caught up with the primary. Different answers for the same record mean something is genuinely broken in replication.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5 \u2014 Walk the delegation chain<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When nothing else explains it, follow the query the way a recursive resolver would \u2014 from the root, down through the TLD, to the authoritative servers:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dig +trace example.com A<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Read it top to bottom. Each block is one hop. The point where the output stops making sense \u2014 a referral to servers that don&#8217;t answer, a missing glue record, an unexpected NXDOMAIN \u2014 is your break point. This single command has saved me more time than any other in DNS troubleshooting.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Reading dig Output Without Guessing<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The status line in a <code>dig<\/code> response tells you the category of failure immediately. Learn these four and you&#8217;ve eliminated most of the guesswork.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>NOERROR<\/strong> \u2014 the query succeeded. Note that NOERROR with an empty answer section is <em>not<\/em> a failure: it means the name exists but has no record of the type you asked for. Asking for an A record on a name that only has MX records gives you exactly this.<\/li><li><strong>NXDOMAIN<\/strong> \u2014 the name does not exist at all. Not a typo in the record; the label itself isn&#8217;t in the zone. Check for a missing record, a misspelled hostname, or a zone that isn&#8217;t loaded.<\/li><li><strong>SERVFAIL<\/strong> \u2014 the resolver tried and failed. This is the ambiguous one, and in practice it usually means DNSSEC validation failure, an authoritative server that&#8217;s unreachable or refusing queries, or a broken delegation.<\/li><li><strong>REFUSED<\/strong> \u2014 the server you asked is not willing to answer for that zone. Typically you&#8217;re querying a server that isn&#8217;t authoritative and doesn&#8217;t do recursion for you.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Two other things worth reading in every response:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>The <code>aa<\/code> flag<\/strong> \u2014 present when the answer came from an authoritative server. If it&#8217;s missing, you&#8217;re looking at a cached answer, and the TTL tells you how stale it might be.<\/li><li><strong>The TTL column<\/strong> \u2014 on a cached answer this counts <em>down<\/em>. Query the same resolver twice a few seconds apart; if the TTL drops, you&#8217;re being served from cache. If it stays constant, you&#8217;re hitting the source.<\/li><\/ul>\n\n\n\n\n<h2 class=\"wp-block-heading\">The Propagation Myth (and What&#8217;s Really Happening)<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">&#8220;DNS propagation takes 24 to 48 hours&#8221; is the most repeated and least accurate sentence in web hosting. Nothing propagates. When you change a record, the authoritative server has the new value instantly. What takes time is the expiry of cached copies held by thousands of independent resolvers \u2014 and that duration is entirely determined by the TTL you set <em>before<\/em> the change.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The practical consequence: lowering a TTL after you&#8217;ve made the change does nothing for anyone who already cached the old value. Plan ahead instead.<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Well before a migration, drop the TTL on the records you&#8217;ll change to something short \u2014 300 seconds is a common choice.<\/li><li>Wait at least the length of the <em>old<\/em> TTL so the short value fully replaces it in caches.<\/li><li>Make the actual change. Old cached answers now expire within minutes.<\/li><li>Verify against several public resolvers and from a couple of different networks.<\/li><li>Once everything is stable, raise the TTL back to something sane \u2014 an hour or more \u2014 so you&#8217;re not paying for lookups you don&#8217;t need.<\/li><\/ol>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">The TTL you set today determines how painful next month&#8217;s migration will be. It&#8217;s the cheapest piece of planning in infrastructure work, and the one most consistently skipped.<\/p>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">One more thing people miss: <strong>negative caching<\/strong>. When a lookup returns NXDOMAIN, resolvers cache that &#8220;doesn&#8217;t exist&#8221; answer too, for a duration derived from the minimum field in the zone&#8217;s SOA record. So if you query a hostname <em>before<\/em> creating it, you may keep getting NXDOMAIN for a while even after the record is live. Check what you&#8217;re in for:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dig +short example.com SOA<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The last number in that output is the negative caching TTL. Resist the urge to test a hostname before you&#8217;ve actually created it.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Failure Patterns You&#8217;ll Meet Again and Again<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">A CNAME on the zone apex<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">You cannot put a plain CNAME on the root of a domain. The apex must carry SOA and NS records, and a CNAME is not allowed to coexist with other records at the same name. Providers work around this with ALIAS, ANAME, or &#8220;CNAME flattening&#8221; records that resolve the target server-side and return an A record. If your root domain misbehaves while <code>www<\/code> is fine, this is the first thing to check.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Stale cache \u2014 everywhere at once<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Correct at the authoritative server, wrong on your machine. Clear caches from the outside in:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Linux with systemd-resolved\nsudo resolvectl flush-caches\n\n# Linux with nscd\nsudo systemctl restart nscd\n\n# macOS\nsudo dscacheutil -flushcache\nsudo killall -HUP mDNSResponder\n\n# Windows (run as Administrator)\nipconfig \/flushdns<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Then remember the browser. Chromium-based browsers keep a separate cache you can clear at <code>chrome:\/\/net-internals\/#dns<\/code>. And if the site uses HSTS, a browser may refuse to fall back to HTTP regardless of what DNS says \u2014 test with <code>curl<\/code> before you conclude anything from a browser.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A forgotten line in \/etc\/hosts<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Someone adds a hosts entry during a migration to test the new server, and never removes it. Six months later the server is &#8220;randomly&#8221; hitting the wrong backend. It costs three seconds to rule out:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep -i example.com \/etc\/hosts\ngetent hosts example.com<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">DNSSEC validation failures<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A domain with broken DNSSEC returns SERVFAIL from validating resolvers while working perfectly on non-validating ones. That produces the maddening symptom where the site loads for some users and not others, with no geographic pattern.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The diagnostic trick is <code>+cd<\/code>, which disables validation. If the query fails normally but succeeds with <code>+cd<\/code>, DNSSEC is your culprit:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dig @1.1.1.1 example.com A\ndig @1.1.1.1 +cd example.com A\n\n# Show the DNSSEC records themselves\ndig example.com DNSKEY +dnssec\ndig example.com DS\n\n# delv performs validation and explains the outcome\ndelv example.com A<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The usual cause is a DS record at the registrar that no longer matches the keys published in the zone \u2014 classic after changing DNS providers without disabling DNSSEC first. <strong>Always turn DNSSEC off at the registrar before migrating name servers, then re-enable it once the new provider is live and stable.<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Split-horizon DNS surprises<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Internal resolvers hand out private addresses; external resolvers hand out public ones. Perfectly intentional \u2014 until a VPN, a container, or a misconfigured search domain puts a client on the wrong side of the split. When a name resolves differently depending on <em>where<\/em> you run the query, compare the local resolver against a public one and check whether a VPN profile is pushing its own DNS servers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Proxied records hiding the origin<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">If a domain sits behind Cloudflare or a similar proxy, public DNS returns the proxy&#8217;s IP, not your server&#8217;s. That&#8217;s the whole point \u2014 but it means you cannot verify an origin change through public DNS at all. Query the authoritative provider&#8217;s own API or dashboard for the real record value, and test the origin directly with <code>curl --resolve<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Wildcards masking a missing record<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A <code>*<\/code> record in the zone means every hostname resolves \u2014 including the ones you typo&#8217;d, and including subdomains you thought you&#8217;d deleted. If everything resolves but half of it points somewhere unexpected, check for a wildcard before you go hunting for phantom records.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Missing trailing dots in zone files<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Hand-editing BIND zone files? A record value without a trailing dot gets the origin appended to it. Write <code>mail.example.com<\/code> instead of <code>mail.example.com.<\/code> and you&#8217;ve just created <code>mail.example.com.example.com<\/code>. Validate before reloading:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>named-checkconf\nnamed-checkzone example.com \/var\/named\/example.com.zone<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And bump the SOA serial. A zone edit without a serial increment won&#8217;t reach the secondaries, which is exactly the inconsistency you were chasing in Step 4.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Containers and the ndots trap<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Inside Kubernetes pods, <code>\/etc\/resolv.conf<\/code> commonly sets <code>ndots:5<\/code>. Any name with fewer than five dots gets tried against every search domain first, so an external lookup like <code>api.example.com<\/code> can generate several failed queries before the correct one. It works \u2014 it&#8217;s just slow, and under load it looks like intermittent DNS failure. Adding a trailing dot to fully qualify the name skips the search list entirely:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/resolv.conf\ndig api.example.com.        # note the trailing dot<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">DNS Troubleshooting for Email Delivery<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Mail problems are DNS problems more often than they are mail-server problems. When messages bounce or land in spam, check these before touching the mail server config:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Where should mail for this domain go?\ndig +short example.com MX\n\n# SPF and DMARC live in TXT records\ndig +short example.com TXT\ndig +short _dmarc.example.com TXT\n\n# DKIM lives under a selector you choose\ndig +short selector1._domainkey.example.com TXT\n\n# Reverse DNS for the sending IP\ndig -x 203.0.113.10 +short<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Things that regularly go wrong here:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Two SPF records.<\/strong> A domain must publish exactly one. Two SPF TXT records is a permanent error, and receiving servers are entitled to fail the check outright. Merge them into one.<\/li><li><strong>An MX pointing at a CNAME.<\/strong> MX targets must resolve to address records, not aliases.<\/li><li><strong>Missing reverse DNS.<\/strong> If the PTR record for your sending IP doesn&#8217;t match the hostname the server announces, expect a lot of spam folder.<\/li><li><strong>DKIM selector mismatch.<\/strong> The selector in the message header must match the one published in DNS \u2014 a detail that quietly breaks after a mail platform migration.<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">While you&#8217;re in TXT territory: if certificate issuance is failing, check for a CAA record. A CAA entry that only authorises one certificate authority will silently block every other one, and the error you get back from the ACME client rarely says &#8220;DNS.&#8221;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>dig +short example.com CAA<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Mistakes That Cost the Most Time<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Testing only in a browser.<\/strong> Browser caches, HSTS, service workers, and QUIC connection reuse will all lie to you. Confirm with <code>dig<\/code> and <code>curl<\/code>.<\/li><li><strong>Trusting the control panel.<\/strong> The dashboard shows what the zone <em>should<\/em> contain. Only a query against the authoritative server shows what it actually serves.<\/li><li><strong>Changing several things at once.<\/strong> Adjust one record, verify, then move on. Batch changes turn a five-minute fix into an archaeology project.<\/li><li><strong>Forgetting IPv6.<\/strong> A stale or wrong AAAA record produces &#8220;works for some people&#8221; behaviour, because dual-stack clients generally prefer IPv6. Always check <code>dig +short example.com AAAA<\/code>.<\/li><li><strong>Leaving DNSSEC enabled through a provider migration.<\/strong> The single most reliable way to take a domain fully offline for hours.<\/li><li><strong>Not documenting the zone before a migration.<\/strong> Export or record every record first. Rebuilding a zone from memory at 2am is not a plan.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices That Prevent the Next Incident<\/h2>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>Use at least two name servers<\/strong>, ideally on separate networks or providers. Single-provider DNS is a single point of failure for your entire presence.<\/li><li><strong>Keep TTLs deliberate.<\/strong> Long TTLs for stable infrastructure, short ones ahead of planned changes. Not the other way round.<\/li><li><strong>Monitor DNS resolution itself<\/strong>, not just HTTP endpoints. A check that queries your authoritative servers directly and alerts on a changed or missing answer catches problems before users do.<\/li><li><strong>Version-control your zone data<\/strong> if your provider supports API or zone-file export. Diffing two zone versions turns &#8220;what changed?&#8221; into a one-second question.<\/li><li><strong>Keep a record inventory<\/strong> \u2014 what each record is for, who owns it, and whether it&#8217;s still needed. Old A records pointing at decommissioned servers are a genuine security risk, not just clutter.<\/li><li><strong>Standardise your checks.<\/strong> A short script that runs your Step 1\u20135 sequence against a domain makes DNS troubleshooting repeatable instead of improvised.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">A Quick Reference You Can Keep<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># Basic resolution\ndig +short example.com A\ndig +short example.com AAAA\n\n# Compare resolvers\ndig +short @1.1.1.1 example.com A\ndig +short @8.8.8.8 example.com A\n\n# Authority and delegation\ndig +short example.com NS\ndig +trace example.com A\ndig +nssearch example.com\n\n# Cache behaviour\ndig example.com A            # watch the TTL count down\ndig +norecurse @1.1.1.1 example.com A   # cached-only lookup\n\n# DNSSEC\ndig +cd example.com A\ndelv example.com A\n\n# Mail and verification records\ndig +short example.com MX\ndig +short example.com TXT\ndig +short _dmarc.example.com TXT\ndig -x 203.0.113.10 +short\n\n# System-level view\nresolvectl status\ngetent hosts example.com\ncat \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">How long does a DNS change really take to take effect?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">At the authoritative server, immediately. For everyone else, up to the TTL that was in place when they last cached the record. If the old TTL was 3600 seconds, worst case is roughly an hour. The &#8220;24 to 48 hours&#8221; figure is a legacy of very long default TTLs and badly behaved resolvers, not a rule.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What&#8217;s the difference between SERVFAIL and NXDOMAIN?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">NXDOMAIN is a definitive answer: the name doesn&#8217;t exist. SERVFAIL means the resolver couldn&#8217;t produce an answer at all \u2014 commonly a DNSSEC validation failure, an unreachable authoritative server, or a broken delegation. NXDOMAIN points you at the zone contents; SERVFAIL points you at the infrastructure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why does the site work for me but not for a colleague?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Different resolvers with different cache states, a hosts file entry on one machine, a VPN pushing internal DNS, an IPv6 versus IPv4 difference, or DNSSEC failing only on validating resolvers. Have both people run the same <code>dig<\/code> against the same public resolver \u2014 if the answers match, the difference is local to one machine.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should I use dig or nslookup?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><code>dig<\/code>, whenever it&#8217;s available. It shows response status, flags, TTLs and the authority section, all of which you need for real DNS troubleshooting. Use <code>nslookup<\/code> or <code>Resolve-DnsName<\/code> when you&#8217;re on a Windows box without other tooling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do online &#8220;DNS propagation checker&#8221; sites actually help?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">They&#8217;re useful for one thing: seeing what different resolvers around the world currently have cached. They won&#8217;t tell you <em>why<\/em> an answer is wrong, and they can&#8217;t see proxied origins or internal split-horizon zones. Treat them as a rough sanity check, not a diagnosis.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can a CNAME point to another CNAME?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Technically yes, and resolvers will follow the chain \u2014 but every extra hop adds latency and another thing to break. Keep chains short, and never let one loop back on itself. Also remember a CNAME cannot coexist with other records at the same name, which is why it doesn&#8217;t belong on a zone apex.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Why do my DNS changes keep reverting?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Usually because something else owns the zone: an infrastructure-as-code pipeline, a control panel that rewrites records on certain actions, or an external DNS controller in a Kubernetes cluster. Decide on one source of truth and make every change through it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is switching to a public resolver a fix?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It&#8217;s a workaround for one user, not a fix for the domain. It&#8217;s genuinely useful as a diagnostic \u2014 if 1.1.1.1 gives the right answer and your ISP&#8217;s resolver doesn&#8217;t, you&#8217;ve isolated the problem to that resolver&#8217;s cache. But if the record itself is wrong, changing resolvers just changes who tells you the wrong thing.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wrapping Up<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Good DNS troubleshooting isn&#8217;t about knowing obscure record types. It&#8217;s about discipline: confirm it&#8217;s DNS, compare resolvers, find out who&#8217;s really authoritative, ask each of them directly, and follow the delegation chain when the answers stop agreeing. Five steps, in order, every time.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Do that consistently and most incidents collapse into something small and obvious \u2014 a stale cache, a TTL nobody lowered, a DS record left behind after a migration, a hosts entry from six months ago. The problems aren&#8217;t usually exotic. They&#8217;re just invisible until you ask the right party the right question.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Keep the quick-reference commands somewhere you can reach in thirty seconds, set your TTLs before you need them, and monitor resolution as seriously as you monitor uptime. Future you will appreciate it at 2am.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Need a Hand With DNS, Hosting or Cloud Infrastructure?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If you&#8217;re stuck on a DNS issue, planning a migration you&#8217;d rather not do twice, or you just want someone to review a zone before you flip the switch, I&#8217;m available for freelance work.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I work on DNS configuration and troubleshooting, domain and hosting migrations, SSL and certificate issues, email deliverability records (SPF, DKIM, DMARC), server setup and hardening, AWS and cloud infrastructure, and monitoring and alerting \u2014 plus WordPress performance and maintenance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">You can see my profile, past work and reviews on Upwork, and message me directly there with what you&#8217;re dealing with.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/www.upwork.com\/freelancers\/~01f15a912ad84a6620\" target=\"_blank\" rel=\"noreferrer noopener\">Hire Me on Upwork<\/a><\/div>\n<\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Got a DNS problem this article didn&#8217;t cover? Leave a comment describing the symptoms and what <code>dig +trace<\/code> shows \u2014 that output alone usually narrows it down fast.<\/p>\n\n<!-- \/wp:post-content -->","protected":false},"excerpt":{"rendered":"<p>Most &#8220;the site is down&#8221; tickets are really DNS problems wearing a costume. Here&#8217;s the practical DNS troubleshooting workflow I use \u2014 how to read dig output, follow the delegation chain, decode SERVFAIL and NXDOMAIN, and stop blaming propagation for things that are actually caching, TTL, or DNSSEC failures.<\/p>\n","protected":false},"author":1,"featured_media":28,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24,26,62,63,64],"tags":[67,71,3,65,68,81,66,77,70,73,69,74,80,83,76,82,79,75,72,78,61],"class_list":["post-27","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-linux","category-networking","category-system-administration","category-web-hosting","tag-bind","tag-cloudflare","tag-devops","tag-dig","tag-dns","tag-dns-cache","tag-dns-records","tag-dns-troubleshooting","tag-dnssec","tag-domain-configuration","tag-linux-networking","tag-mx-records","tag-nameservers","tag-network-debugging","tag-nslookup","tag-nxdomain","tag-servfail","tag-spf","tag-sysadmin","tag-ttl","tag-web-hosting","entry","has-media"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.1 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>DNS Troubleshooting: A Practical Guide for Sysadmins<\/title>\n<meta name=\"description\" content=\"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"DNS Troubleshooting: A Practical Guide for Sysadmins\" \/>\n<meta property=\"og:description\" content=\"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/\" \/>\n<meta property=\"og:site_name\" content=\"John Nessime\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-30T13:50:39+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-30T13:50:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1536\" \/>\n\t<meta property=\"og:image:height\" content=\"1024\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"John Nessime\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"John Nessime\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"15 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/\"},\"author\":{\"name\":\"John Nessime\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"headline\":\"DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours\",\"datePublished\":\"2026-07-30T13:50:39+00:00\",\"dateModified\":\"2026-07-30T13:50:42+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/\"},\"wordCount\":3292,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"image\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png\",\"keywords\":[\"BIND\",\"Cloudflare\",\"DevOps\",\"dig\",\"DNS\",\"DNS Cache\",\"DNS Records\",\"DNS Troubleshooting\",\"DNSSEC\",\"Domain Configuration\",\"Linux Networking\",\"MX Records\",\"Nameservers\",\"Network Debugging\",\"NSlookup\",\"NXDOMAIN\",\"SERVFAIL\",\"SPF\",\"Sysadmin\",\"TTL\",\"Web Hosting\"],\"articleSection\":[\"DevOps\",\"Linux\",\"Networking\",\"System Administration\",\"Web Hosting\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/\",\"name\":\"DNS Troubleshooting: A Practical Guide for Sysadmins\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png\",\"datePublished\":\"2026-07-30T13:50:39+00:00\",\"dateModified\":\"2026-07-30T13:50:42+00:00\",\"description\":\"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#primaryimage\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png\",\"contentUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png\",\"width\":1536,\"height\":1024,\"caption\":\"DNS troubleshooting workflow showing a terminal with dig command output and a diagram of the DNS resolution chain from resolver to root, TLD, and authoritative name servers\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/networking\\\/dns-troubleshooting\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/\",\"name\":\"John Nessime\",\"description\":\"Cloud, DevOps, Data &amp; AI \u2014 Built, Tested, Explained\",\"publisher\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/#\\\/schema\\\/person\\\/ede0b56d0c808f123f57d5d796902105\",\"name\":\"John Nessime\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"contentUrl\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\",\"width\":512,\"height\":512,\"caption\":\"John Nessime\"},\"logo\":{\"@id\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/cropped-jn.png\"},\"description\":\"AWS Certified Solutions Architect helping businesses build reliable cloud, data, reporting, and automation solutions. I help startups, agencies, and growing businesses replace manual processes and disconnected data with practical AWS architectures, clean data pipelines, useful dashboards, and maintainable automation.\",\"sameAs\":[\"https:\\\/\\\/john-nessime.com\\\/blog\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/john-m-nessime\"],\"url\":\"https:\\\/\\\/john-nessime.com\\\/blog\\\/author\\\/johnnessime\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"DNS Troubleshooting: A Practical Guide for Sysadmins","description":"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/","og_locale":"en_US","og_type":"article","og_title":"DNS Troubleshooting: A Practical Guide for Sysadmins","og_description":"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.","og_url":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/","og_site_name":"John Nessime","article_published_time":"2026-07-30T13:50:39+00:00","article_modified_time":"2026-07-30T13:50:42+00:00","og_image":[{"width":1536,"height":1024,"url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png","type":"image\/png"}],"author":"John Nessime","twitter_card":"summary_large_image","twitter_misc":{"Written by":"John Nessime","Est. reading time":"15 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#article","isPartOf":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/"},"author":{"name":"John Nessime","@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"headline":"DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours","datePublished":"2026-07-30T13:50:39+00:00","dateModified":"2026-07-30T13:50:42+00:00","mainEntityOfPage":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/"},"wordCount":3292,"commentCount":0,"publisher":{"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"image":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#primaryimage"},"thumbnailUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png","keywords":["BIND","Cloudflare","DevOps","dig","DNS","DNS Cache","DNS Records","DNS Troubleshooting","DNSSEC","Domain Configuration","Linux Networking","MX Records","Nameservers","Network Debugging","NSlookup","NXDOMAIN","SERVFAIL","SPF","Sysadmin","TTL","Web Hosting"],"articleSection":["DevOps","Linux","Networking","System Administration","Web Hosting"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/","url":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/","name":"DNS Troubleshooting: A Practical Guide for Sysadmins","isPartOf":{"@id":"https:\/\/john-nessime.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#primaryimage"},"image":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#primaryimage"},"thumbnailUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png","datePublished":"2026-07-30T13:50:39+00:00","dateModified":"2026-07-30T13:50:42+00:00","description":"DNS troubleshooting made practical: use dig, trace delegation, decode SERVFAIL and NXDOMAIN, fix stale caches, TTL and DNSSEC issues fast.","breadcrumb":{"@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#primaryimage","url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png","contentUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/DNS-Troubleshooting-How-to-Find-the-Real-Cause-in-Minutes-Not-Hours.png","width":1536,"height":1024,"caption":"DNS troubleshooting workflow showing a terminal with dig command output and a diagram of the DNS resolution chain from resolver to root, TLD, and authoritative name servers"},{"@type":"BreadcrumbList","@id":"https:\/\/john-nessime.com\/blog\/networking\/dns-troubleshooting\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/john-nessime.com\/blog\/"},{"@type":"ListItem","position":2,"name":"DNS Troubleshooting: How to Find the Real Cause in Minutes, Not Hours"}]},{"@type":"WebSite","@id":"https:\/\/john-nessime.com\/blog\/#website","url":"https:\/\/john-nessime.com\/blog\/","name":"John Nessime","description":"Cloud, DevOps, Data &amp; AI \u2014 Built, Tested, Explained","publisher":{"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/john-nessime.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/john-nessime.com\/blog\/#\/schema\/person\/ede0b56d0c808f123f57d5d796902105","name":"John Nessime","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","url":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","contentUrl":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png","width":512,"height":512,"caption":"John Nessime"},"logo":{"@id":"https:\/\/john-nessime.com\/blog\/wp-content\/uploads\/2026\/07\/cropped-jn.png"},"description":"AWS Certified Solutions Architect helping businesses build reliable cloud, data, reporting, and automation solutions. I help startups, agencies, and growing businesses replace manual processes and disconnected data with practical AWS architectures, clean data pipelines, useful dashboards, and maintainable automation.","sameAs":["https:\/\/john-nessime.com\/blog","https:\/\/www.linkedin.com\/in\/john-m-nessime"],"url":"https:\/\/john-nessime.com\/blog\/author\/johnnessime\/"}]}},"_links":{"self":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/27","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/comments?post=27"}],"version-history":[{"count":1,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/27\/revisions"}],"predecessor-version":[{"id":29,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/posts\/27\/revisions\/29"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/media\/28"}],"wp:attachment":[{"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/media?parent=27"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/categories?post=27"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/john-nessime.com\/blog\/wp-json\/wp\/v2\/tags?post=27"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}