When to Use nslookup vs dig for DNS Queries

You open a terminal to chase a DNS problem and find two tools already there: nslookup and dig. Both send DNS queries and return records, but they were built with different goals and expose different levels of protocol detail. Using the wrong one can leave you with an incomplete picture at exactly the moment you need clarity most. This guide covers what each tool actually does, where each one falls short, and a clear rule for which to reach for in every situation — including how DNSSEC, DNS-over-HTTPS, and IPv6 change the picture in 2026.

What nslookup Is and What It Does Well

nslookup ("name server lookup") has shipped with every Windows version since XP, comes preinstalled on macOS, and is available on Linux via the bind-utils or dnsutils package. It runs in two modes: non-interactive (one command, one result) and interactive (an open session for multiple queries). Most people use the non-interactive form:

Output is clean and human-readable. It strips protocol noise and delivers the answer section in a format easy to paste into a support ticket or share with a non-technical colleague. That readability is nslookup's genuine strength. The weaknesses are structural: TTLs are not shown in the default output, the authority section is absent unless you enable debug mode, and DNSSEC records are invisible no matter what flags you pass. If the DNS answer has subtleties — a TTL mismatch, a broken signature, an inconsistent secondary — nslookup will not surface them.

The interactive mode earns its place during exploratory sessions. You can switch record types and nameservers mid-session without retyping the hostname each time:

What dig Is and Why It Is the Standard for Serious DNS Work

dig ("domain information groper") was written by ISC as part of the BIND project and has been the preferred tool of DNS engineers for decades. It ships on macOS 10.9 and later and virtually all Linux distributions. On Windows it does not ship natively — more on that in the platform section below. Unlike nslookup, dig returns the full DNS message: question section, answer section, authority section, additional section, query flags, which server responded, and query time in milliseconds. For the same MX lookup that nslookup handles in two lines, dig gives you the complete protocol trace:

The +short flag strips everything except the answer — useful when you only need the IP or record value. At the other extreme, +all shows every section of the DNS message. The timing data at the bottom of every dig response is invisible in nslookup but critical when baselining resolver performance or diagnosing slow DNS resolution on a WAN link. For a deeper look at how DNS queries and responses are structured at the protocol level, RFC 1034 is the foundational specification and still the most authoritative reference.

The Differences That Actually Matter

TTL Visibility

nslookup does not show TTLs in its default output. To expose them you must run nslookup -debug example.com and parse a wall of raw packet data. dig shows TTLs inline on every record line in the answer section, with no extra flags required. When you change an A record and need to track exactly when caches will expire the old value, dig tells you immediately. Keep in mind that the TTL shown is the remaining TTL on that particular resolver's cached copy — it counts down from the original value as the resolver holds it. A 3600-second record queried 30 minutes after a change will show 3420 remaining on a resolver that fetched it at the moment of the change.

DNSSEC Support

dig has deep, first-class DNSSEC support. You can request the DO (DNSSEC OK) bit, view RRSIG records, check DS records at the parent zone, and trace the chain of trust from root to leaf:

The +cd flag is the key diagnostic for DNSSEC failures. If a standard query returns SERVFAIL but the same query with +cd returns a record, the DNSSEC signature is broken or the DS record is mismatched at the parent zone. As of 2026, both Cloudflare (1.1.1.1) and Google (8.8.8.8) validate DNSSEC by default, which means a broken signature causes silent failures for a large proportion of end users. nslookup cannot diagnose this condition at all. It will return the record if the resolver passes it back, or return a generic error with no indication that DNSSEC is the cause.

Scripting and Automation

dig's +short output returns one value per line, making it trivial to pipe into grep, awk, or a bash loop. A common pattern for verifying that all authoritative nameservers return the same answer:

nslookup's output format shifts depending on record count, whether the result is canonical, and whether it is running interactively or not. Parsing nslookup in a script produces brittle code that breaks when record counts change or when error message formats differ across operating systems. For any DNS work involving a script, loop, or automated check, dig is the correct choice.

Transport and Protocol Controls

dig exposes transport flags that nslookup lacks entirely. +tcp forces TCP instead of UDP — essential when diagnosing firewall rules that truncate large UDP DNS responses or block UDP/53 outright. +norecurse sends a non-recursive query to an authoritative server directly. +bufsize controls the EDNS payload size. These matter in real troubleshooting scenarios:

Batch Mode

dig accepts a file of queries via the -f flag: one query per line, processed in sequence with consistent output formatting:

nslookup has no non-interactive batch equivalent. Its interactive mode accepts multiple queries but cannot be driven by a file for unattended use.

When nslookup Is the Right Choice

• Windows without WSL installed: nslookup is already there. On a Windows Server you have just remoted into with no additional tooling, it is your fastest path to an answer.
• Quick existence checks: "Does this hostname resolve to the right IP?" — nslookup delivers a clean two-line answer without any noise.
• Sharing results with non-technical stakeholders: nslookup output is easier to interpret for someone who does not work with DNS daily. Pasting it into a support ticket is cleaner than raw dig output with six sections.
• Interactive zone exploration: When you do not yet know which record type you need, the nslookup session lets you pivot record types and resolvers mid-query without retyping the hostname each time.

When dig Is the Right Choice

• TTL tracking: You changed a record and need to monitor exactly when it expires from specific caches.
• DNSSEC debugging: Broken signatures, mismatched DS records, NSEC gaps, or SERVFAIL responses that may be validation failures rather than missing records.
• Authoritative server testing: Querying each NS record directly with +norecurse to confirm they all return consistent answers independently of the recursive resolver chain.
• Propagation auditing: Scripted loops across nameservers or public resolver lists to verify globally consistent resolution.
• Zone transfer verification: AXFR queries to confirm replication between primary and secondary nameservers.
• Latency baselining: The per-query millisecond timing at the bottom of every dig response lets you compare resolver response times across multiple upstreams.

Command Reference: nslookup and dig Side by Side

Platform Availability in 2026

Windows

nslookup ships on every Windows version. dig does not. Three paths to get dig on Windows: (1) enable WSL and install dnsutils inside the Linux environment — the recommended approach for anyone doing regular DNS work, (2) download the BIND tools package from ISC which includes a native dig.exe for Windows, or (3) install via Chocolatey with choco install bind-toolsonly. PowerShell's Resolve-DnsName cmdlet is a fourth option but lacks DNSSEC output and scriptable formatting. On Windows 11 24H2 and Windows Server 2025, neither nslookup nor Resolve-DnsName exposes DNSSEC data. WSL plus dig is the standard recommendation for serious DNS work on Windows in 2026.

macOS

Both tools ship on macOS. On Apple Silicon and macOS 14 Sonoma onward, both still work correctly from Terminal. macOS routes default queries through mDNSResponder, which can return different results than a public resolver when the machine is on a split-horizon network or using a VPN with DNS override. To bypass the system resolver and query a specific server directly:

Linux

Install via your package manager if the tools are not already present:

On distributions using systemd-resolved — Ubuntu 20.04 and later, Debian 12 and later, Fedora 33 and later — the stub resolver at 127.0.0.53 intercepts all queries by default. Both dig and nslookup hit this stub unless you specify a different server. To bypass it and test the upstream resolver directly, add @1.1.1.1 or @8.8.8.8 explicitly. The resolvectl command provides information neither dig nor nslookup can give you on these systems: per-interface DNS servers, the actual upstream addresses systemd-resolved is using, and DNSSEC validation status per link:

iOS and Android

Neither tool is available on stock mobile operating systems. On Android, Termux provides a full terminal without requiring root:

On non-rooted Android and on iOS, applications like Network Analyzer provide dig-equivalent DNS lookup functionality from the UI. For propagation checking from a mobile device, a web-based tool is typically faster and more complete than a mobile terminal.

DoH, DoT, and Why Your Results May Not Match What the Browser Sees

Both nslookup and dig query DNS over UDP or TCP on port 53. Neither natively supports DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). In 2026 this is a meaningful gap:

• Chrome, Firefox, and Edge have DoH enabled by default for many users, routing through Cloudflare or Google as the encrypted upstream — completely separate from whatever resolver dig queries on the same machine.
• iOS 14 and later and Android 9 and later support Private DNS (DoT). A device configured with a custom Private DNS address resolves independently of what your local dig output shows.
• If a user reports DNS results that contradict your dig output, check their browser's secure DNS setting before assuming a propagation issue. In Chrome: Settings → Privacy and security → Security → Use secure DNS. In Firefox: Settings → Privacy and Security → DNS over HTTPS.

To test a DoH endpoint from the command line without installing specialized tools:

For IPv6, both tools handle AAAA records correctly. dig's -6 flag forces the query transport itself over IPv6, which is useful for verifying that your resolver is reachable on an IPv6-only path:

Common Misdiagnoses

• "nslookup resolves it but the browser doesn't": The browser is almost certainly using DoH to a different upstream resolver, or a hosts file entry is overriding DNS resolution entirely. Check the browser's secure DNS setting and verify C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux and macOS.
• "dig returns NXDOMAIN but nslookup shows a result": Almost always a resolver mismatch. dig shows the responding server at the top of output as ;; SERVER: 127.0.0.53#53, and nslookup shows it as Server: in its header. Confirm both tools are querying the same resolver before drawing any conclusions.
• "TTL is still high but propagation should be finished": The TTL in dig's answer section is the remaining TTL on that specific resolver's cached copy, not a global indicator. Other resolvers may have already refreshed or may still hold the old record with their own remaining TTL. Check multiple vantage points simultaneously to get an accurate propagation picture.
• "dig in WSL shows different results than nslookup on the same Windows machine": WSL maintains its own /etc/resolv.conf that may point to a completely different nameserver than the Windows DNS stack. This is expected behavior and often useful — it means you are genuinely testing two separate resolvers from one machine.

The Three-Step Verification Workflow

Regardless of which tool you use, this sequence pinpoints where a DNS discrepancy originates:

1. Query the authoritative nameserver directly without recursion to confirm what the zone file says.
2. Query a public resolver to confirm what the broader internet sees.
3. Query your local resolver with default settings to confirm what your own network sees.

If steps 1 and 2 disagree, there is a propagation delay or a secondary nameserver replication failure. If steps 2 and 3 disagree, your local resolver is serving stale cached data. The same logic applies with nslookup, but dig gives you TTLs and the full authority section that make the comparison sharper and significantly faster to interpret.

The Bottom Line

Use nslookup when you are on Windows without WSL, doing a quick existence check, or sharing output with someone who does not work with DNS daily. Use dig for everything else: DNSSEC validation, TTL monitoring, authoritative server testing, scripted automation, and any situation where you need the complete DNS response rather than just the answer. On Linux and macOS, make dig your default. On Windows, nslookup covers the basics until WSL is set up — then dig takes over permanently.