How to Use the dig Command for DNS Lookups in 2026

The dig command is the go-to DNS diagnostic tool for anyone who manages websites, troubleshoots email delivery, or wants to see exactly what the internet reports for a domain. Unlike browser-based lookups, dig gives you the raw DNS server response — record type, TTL, authoritative server, query status, and all. This tutorial gets you from zero to confident.

What Is dig?

dig (Domain Information Groper) is a command-line DNS query tool maintained by the Internet Systems Consortium as part of the BIND toolkit. You send it a domain name and a record type, and it prints the full structured DNS response directly from whatever resolver you point it at — no caching layers, no browser magic in the way. Network engineers and sysadmins reach for it first because it shows exactly what is happening at the protocol level, including TTLs, DNSSEC signatures, and authority chain details that GUI tools hide.

Compared to nslookup — which ships pre-installed on Windows — dig is more scriptable, produces cleaner structured output, and supports modern DNS features including DNSSEC and EDNS0 extensions. If you are on Windows and only have nslookup today, the installation section below is worth five minutes of your time.

Installing dig

Linux

dig is part of the bind-utils or dnsutils package depending on your distribution:

macOS

dig ships pre-installed with macOS. Open Terminal and run dig --version to confirm. No installation needed. Apple bundles a slightly older BIND build, but it handles every query type covered in this tutorial without issue.

Windows

Windows ships with nslookup but not dig. Three installation paths, in order of convenience:

• WSL2 (recommended): Enable Windows Subsystem for Linux, install Ubuntu from the Microsoft Store, then run sudo apt-get install dnsutils inside it. You get a full Linux dig experience inside Windows Terminal.
• Chocolatey: Run choco install bind-toolsonly in an elevated PowerShell prompt to install a standalone dig.exe for Windows.
• BIND for Windows: Download the current stable Windows build from the ISC BIND download page, extract the archive, and add the folder to your system PATH. Open a new Command Prompt and run dig --version to confirm it is on the path.

On Windows, be aware that dig.exe and nslookup can disagree if they are pointed at different resolvers by default. Always use @server explicitly when precision matters.

Basic Syntax

The dig command follows this pattern:

• @server — DNS resolver to query (optional; uses your system default if omitted)
• name — the domain name to look up
• type — record type: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR
• options — flags that start with +, such as +short or +trace

Arguments can appear in any order. dig A example.com and dig example.com A both work.

Your First dig Query

Run a plain lookup with no flags:

The output has five structured sections:

1. Header: query ID, status code (NOERROR, NXDOMAIN, SERVFAIL), and flags — qr means query response, aa means authoritative answer, rd means recursion desired, ra means recursion available
2. Question section: echoes back what you asked
3. Answer section: the returned DNS records
4. Authority section: nameservers that can answer authoritatively (may be empty for cached responses)
5. Statistics: query time in milliseconds, resolver IP used, timestamp, and raw message size in bytes

A typical answer section entry looks like this:

Reading left to right: the FQDN (the trailing dot is correct DNS notation from RFC 1035, not a display bug), TTL in seconds, record class (IN = Internet), record type, and value. TTL 3600 means resolvers may cache this record for up to one hour before re-querying the authoritative server.

Querying Specific Record Types

A and AAAA — IPv4 and IPv6 Addresses

In 2026, production domains should have both A and AAAA records. If users on IPv6 networks cannot reach a site while IPv4 users can, a missing or misconfigured AAAA record is the first thing to check. Use the -4 flag to force dig itself to use IPv4 transport, or -6 for IPv6 transport — this controls the transport layer, not the record type being queried.

MX — Mail Servers

MX records include a priority number. Lower value means higher priority. When email delivery is failing, confirming the MX record matches your mail provider's documented hostname is the first CLI check before diving into mail logs. If multiple MX records share the same priority number, delivery is load-balanced across them.

TXT — Text Records

TXT records carry SPF policies, DKIM public keys, DMARC policies, and domain ownership verification tokens. SPF lives at the apex domain. DKIM keys live at a selector subdomain — for example, default._domainkey.example.com. DMARC lives at _dmarc.example.com. When troubleshooting bounced mail or failed DKIM signatures, these three subdomains are the ones to query.

NS — Nameservers

NS records identify which nameservers are authoritative for the zone. After transferring a domain or switching DNS providers, querying NS from an external resolver like 8.8.8.8 confirms whether the delegation change has propagated. If the NS records returned differ from what your registrar dashboard currently shows, the change is still in transit.

CNAME — Aliases

A CNAME points one hostname to another. An empty answer section means either the record does not exist or you are hitting CNAME flattening — a technique used by Cloudflare and other CDNs that resolves apex CNAMEs to A records automatically, hiding the intermediate CNAME from the response. Use +trace to see what each delegation layer returns step by step.

SOA — Start of Authority

The SOA record contains the primary nameserver, the zone admin email (the first dot in the name field maps to the @ sign), a serial number, and the refresh, retry, expire, and minimum TTL values for the zone. Comparing SOA serial numbers across two authoritative nameservers for the same domain reveals instantly whether the secondary is behind the primary — a common root cause of intermittent resolution failures when half of the NS records return stale data.

The Most Useful dig Flags

+short

Strips all output except the answer values. Ideal for shell scripts and quick lookups where you just need the IP:

+noall +answer

Shows only the answer section with full record detail including TTL — more useful than +short when the TTL value itself matters:

@server — Query a Specific Resolver

Override your system resolver to query a different DNS server. This is the core technique for isolating propagation problems:

If @8.8.8.8 returns the new IP but @1.1.1.1 still returns the old one, propagation is mid-flight. If the authoritative nameserver itself returns the old record, the zone was not updated correctly — that is where the fix belongs, not at the propagation layer.

+trace — Walk the Full DNS Hierarchy

Forces dig to start at the root servers and follow every delegation step down to the authoritative nameserver, ignoring all cached data:

Output shows the root server response, then the TLD nameserver response, then the authoritative nameserver response — every hop labeled. Delegation mismatches (where a registrar still points to old nameservers after a provider change) appear here as a mismatch between the TLD's delegation and what the NS records currently claim. This is the single most powerful flag for diagnosing hard-to-reproduce resolution failures.

Reverse DNS — The -x Flag

Find the hostname associated with an IP address by querying the PTR record:

For IPv6 addresses, the same flag works — dig translates the address to the ip6.arpa zone format automatically:

Missing PTR records are among the most common causes of spam filter rejections for outbound mail servers. If your sending IP returns NXDOMAIN on a reverse lookup, contact your hosting provider to have a PTR record set before investigating other deliverability issues — most spam filters check PTR existence before evaluating SPF or DKIM.

Checking DNS Propagation with dig

When a DNS change is fresh and you want to know where it has landed, query multiple resolvers in a loop:

The TTL in the answer section represents the maximum time the old record can persist in downstream caches. A record with TTL 86400 that you changed today can survive in ISP resolver caches for up to 24 hours. The standard prevention technique: lower the TTL to 300 seconds 24 to 48 hours before any planned DNS cutover, then restore it after the new record is confirmed live everywhere. Note that some ISP resolvers apply their own TTL floor and ignore very short values — this is why propagation can sometimes outlast the published TTL.

DNSSEC Verification with dig

DNSSEC adds cryptographic signatures to DNS records so validating resolvers can detect forged or tampered responses in transit. To check whether a domain's records are signed:

If DNSSEC is active, the answer section includes an RRSIG record alongside each signed record. Two additional flags are essential for DNSSEC diagnostics:

When a resolver returns the ad flag, the full DNSSEC chain from the root trust anchor down to the zone has been validated successfully. If a domain has a broken DNSSEC chain, validating resolvers return SERVFAIL and the domain becomes unreachable for users on those resolvers. Use +cd to bypass validation and see the raw records for diagnosis. To walk the entire trust chain and see exactly where it breaks:

DoH and DoT in 2026

dig speaks traditional UDP and TCP DNS on port 53 and does not natively support DNS over HTTPS (DoH) or DNS over TLS (DoT). This matters because most clients in 2026 — browsers, Windows 11, macOS 13+, Android 9+, and iOS 14+ — use encrypted DNS by default, meaning their effective resolver may differ from the system resolver that dig queries. A successful dig result is not always proof that a browser will see the same record.

To test a DoH endpoint from the command line, use curl:

For DoT queries, install kdig from the Knot DNS tools package and run:

When a user reports a site works on their phone but is broken on their laptop, one explanation is that the two devices are using different encrypted resolvers with different cache states. Confirm by running dig on the laptop explicitly against the same resolver the phone uses — for most iPhones with iCloud Private Relay off, that is the carrier DNS or 1.1.1.1 if DoH is enabled in Settings.

Linux: Using resolvectl Alongside dig

On systemd-based distributions — Ubuntu 20.04+, Debian 11+, Fedora — DNS queries go through systemd-resolved. Its companion CLI is resolvectl:

A common source of confusion: /etc/resolv.conf on these systems typically points to 127.0.0.53, the systemd-resolved stub listener. Running dig @127.0.0.53 example.com goes through systemd-resolved including its DNSSEC validation. Running dig @8.8.8.8 example.com bypasses it entirely. If those two queries return different results, systemd-resolved's local validation policy or negative caching is the variable to investigate — check resolvectl status to see its current DNSSEC setting per interface.

To flush the local DNS cache without restarting the service:

Flushing DNS Cache on macOS and Windows

dig on macOS bypasses the mDNSResponder system cache and queries the configured resolver directly, so dig results can diverge from what Safari or Chrome sees from their local cache. To clear the macOS DNS cache:

On Windows, flush with:

After flushing, rerun dig and reload the browser. If dig now returns the updated record but the browser still hits an old address, the browser has its own internal DNS cache separate from the OS. In Chrome, clear it at chrome://net-internals/#dns. In Firefox, go to about:networking#dns. This three-layer cache model — OS resolver cache, browser DNS cache, DoH resolver cache — is a common source of misdiagnosis when dig says one thing and the browser shows another.

Common Mistakes to Avoid

• Using the ANY query type: dig example.com ANY used to return every record type at once. Since RFC 8482 (2019), most resolvers return a minimal or empty response to ANY queries. Query each record type explicitly for reliable results.
• Confusing NXDOMAIN with SERVFAIL: NXDOMAIN means the name genuinely does not exist in the zone. SERVFAIL means the nameserver encountered an error — most often a DNSSEC validation failure or a broken referral. They require entirely different fixes and are not interchangeable.
• Assuming dig uses the same resolver as the browser: Chrome and Firefox may use a DoH resolver configured separately from the OS DNS settings that dig reads. A result match between dig and the browser is a coincidence unless you have confirmed they share the same resolver.
• Treating TTL as exact propagation time: TTL is the maximum cache lifetime a resolver is allowed to honor. ISP resolvers may apply a TTL floor and cache records longer than the published value, causing propagation to outlast the TTL you set.
• Reading the trailing dot as a typo: In dig output, example.com. ends with a dot because dig displays fully qualified domain names as defined in RFC 1035. It is correct notation, not a rendering artifact.
• Querying without specifying a type and expecting all records: dig example.com with no type defaults to A records only, not all record types. Explicitly state the type for every production diagnostic query.

Quick Reference

The DNS protocol specification (RFC 1035) defines the query and response format that dig uses at the wire level. When dig output surprises you — unexpected flags set, unexpected record counts, truncation — the RFC is the authoritative source for what the protocol guarantees and what it deliberately leaves to implementation.