The latest articles on DEV Community by Roman (@r0men_). https://dev.to/r0men_ https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3938619%2F52fc1df1-199d-459d-9573-c3a9cf9b178c.jpg https://dev.to/r0men_ en Roman Thu, 27 Aug 2026 15:12:38 +0000 https://dev.to/r0men_/understanding-dig-how-to-actually-read-dns-query-output-4bld https://dev.to/r0men_/understanding-dig-how-to-actually-read-dns-query-output-4bld <p>If you've ever stared at the output of <code>dig example.com</code> and only understood half of it, you're not alone. <code>dig</code> (Domain Information Groper) is the tool most sysadmins and DevOps engineers reach for first when a domain "isn't resolving" — but its output is dense, and knowing which line actually matters saves a lot of guessing.</p> <p>Here's a quick breakdown of what a <code>dig</code> response is telling you and how to use it for real troubleshooting.</p> <h2> The four things <code>dig</code> output actually tells you </h2> <p>A <code>dig</code> response is split into sections, each answering a different question:</p> <ul> <li> <strong>HEADER</strong> — the response status (<code>NOERROR</code>, <code>NXDOMAIN</code>, <code>SERVFAIL</code>) plus flags like <code>aa</code> (authoritative) and <code>rd</code>/<code>ra</code> (recursion desired/available).</li> <li> <strong>QUESTION SECTION</strong> — confirms exactly what was asked.</li> <li> <strong>ANSWER SECTION</strong> — the actual record returned, in <code>name TTL class type value</code> format.</li> <li> <strong>Query time / SERVER / WHEN</strong> — how fast the resolver answered, and which resolver it was.</li> </ul> <p>The status code alone usually tells you what's wrong before you read anything else:</p> <ul> <li> <code>NOERROR</code> + empty answer → the domain exists, but has no record of the type you asked for.</li> <li> <code>NXDOMAIN</code> → the domain doesn't exist — typo, expired registration, or a deleted zone.</li> <li> <code>SERVFAIL</code> → the authoritative name servers themselves are broken. That's a registrar/DNS-provider problem, not something on your end.</li> </ul> <h2> Picking the right record type </h2> <p>A domain doesn't have one DNS record — it has several, and <code>dig</code> needs to know which one you're asking for:</p> <ul> <li> <code>A</code> / <code>AAAA</code> — the IPv4/IPv6 address.</li> <li> <code>MX</code> — mail server routing and priority. First thing to check when email bounces.</li> <li> <code>TXT</code> — SPF, DKIM, and domain-ownership verification strings.</li> <li> <code>NS</code> — the authoritative name servers. Wrong here means nothing else resolves correctly.</li> <li> <code>CNAME</code> — an alias pointing one hostname at another.</li> <li> <code>SOA</code> — primary name server, admin contact, zone refresh/retry/expire timers.</li> <li> <code>PTR</code> — reverse lookup (IP → hostname). Query format is different — more on that below.</li> </ul> <h2> <code>+short</code>: skip the noise </h2> <p>Once you know what you're looking for, <code>dig example.com A +short</code> strips the response down to bare values — just the IPs, one per line. No header, no timing info, nothing else.</p> <h2> Querying a specific resolver </h2> <p><code>dig @1.1.1.1 example.com A</code> sends the query straight to a specific resolver instead of your system default. This is the fastest way to explain "it works for them but not for me" — DNS changes don't propagate everywhere simultaneously, and your ISP's resolver may be serving a stale cached record while a public resolver already reflects the update. Querying two <code>@server</code>s side by side turns a mystery into "oh, it's just caching."</p> <h2> The PTR gotcha </h2> <p><code>dig 203.0.113.10 PTR</code> doesn't work the way you'd expect, because PTR records live under a reversed, special-purpose domain: <code>10.113.0.203.in-addr.arpa</code>. If a reverse lookup returns <code>NXDOMAIN</code> for an IP you <em>know</em> is active, check the octet order before assuming reverse DNS isn't configured.</p> <h2> <code>dig</code> vs <code>whois</code> vs <code>host</code> </h2> <p>They answer different questions, and mixing them up wastes time:</p> <ul> <li> <code>dig</code> — what does this domain resolve to <em>right now</em>, according to this resolver.</li> <li> <code>host</code> — the same core answer, shorter and more script-friendly.</li> <li> <code>whois</code> — who registered the domain and when it expires. Registration metadata, not live DNS.</li> </ul> <h2> Two real troubleshooting patterns </h2> <p><strong>"We updated DNS an hour ago and some people still see the old value."</strong> Query against two different <code>@server</code>s. If they disagree, it's propagation/caching — wait out the TTL rather than touching the config again.</p> <p><strong>"Email is bouncing."</strong> <code>dig yourdomain.com MX +short</code> first. If it's empty, mail has nowhere to go. If MX is fine, check <code>TXT</code> next — a missing or malformed SPF record is a very common silent-bounce cause.</p> <h3> Read more / try it live </h3> <p>This post covers the basics — the full guide goes deeper into DNSSEC validation (<code>+dnssec</code>), why <code>+trace</code> isn't always the tool you want, and includes a live sandboxed <code>dig</code> you can actually run against a real domain, right in the browser, with no install:</p> <p>👉 <strong><a href="https://linuxcli.xyz/commands/dns/dig" rel="noopener noreferrer">Read the full dig command guide</a></strong></p> dns linux networking devops