This article shows you the most useful dig command examples for everyday DNS troubleshooting, from a simple lookup to tracing the full resolution path. You enter a domain name and an optional record type or flag, and dig prints the DNS answer, the authority, and timing information directly in your terminal.
What Is dig and Why Use It
dig (Domain Information Groper) is a command-line tool for querying DNS servers. It is part of the dnsutils package on Debian/Ubuntu and bind-utils on RHEL/CentOS/Fedora. It is the standard tool for DNS debugging because it gives you the raw response, shows every section of the DNS message, and lets you specify the exact server, port, and protocol. Unlike nslookup, which is older and sometimes prints confusing defaults, dig output is structured and predictable.
Basic Lookup: A and AAAA Records
The most common use is a simple A record lookup:
dig example.com
This queries your system’s default resolver for the IPv4 address. The output has five sections: the header (status, opcode), the question (what you asked), the answer (the records), the authority (the nameservers), and the additional (glue records). The ANSWER SECTION is what you usually want. To get IPv6 addresses, use:
dig example.com AAAA
You can also ask for any record type: MX, NS, TXT, CNAME, SOA, PTR, CAA, and so on. For example:
dig example.com MX
This returns the mail exchangers in priority order.
Short Output with +short
The default output is verbose. When you only want the answer value, add +short:
dig example.com +short
This prints just the IP addresses, one per line. For MX records, it prints the priority and hostname. This is ideal for scripting. Combine it with +noall and +answer to show only the answer section without the header and footer:
dig example.com +noall +answer
That gives you the full record name, TTL, class, type, and value, but nothing else.
Querying a Specific DNS Server
By default, dig uses the resolver in /etc/resolv.conf. To query a specific server, put an @ sign before the server address:
dig @8.8.8.8 example.com
This sends the query directly to Google’s public DNS. You can use any IP or hostname. This is useful when you suspect your local resolver is caching stale data, or when you want to compare answers between different providers. For example:
dig @1.1.1.1 example.com +short
will show Cloudflare’s answer, which may differ from your ISP’s.
Reverse DNS Lookups (PTR Records)
To find the hostname for an IP address, use -x:
dig -x 8.8.8.8
This performs a reverse lookup by converting the IP into the special in-addr.arpa domain and querying for a PTR record. The answer shows the canonical name for that address. This is useful for verifying mail server reverse DNS or for troubleshooting why a hostname does not resolve.
Tracing the Full Resolution Path
The +trace flag walks the DNS hierarchy from the root servers down:
dig example.com +trace
This starts at the root (.) servers, then asks the .com TLD servers, then the authoritative nameservers for example.com. Each step shows which server was queried and what it returned. This is the best way to see where a resolution fails: a root server problem, a TLD problem, or an authoritative problem. It also shows you the delegation chain and confirms that the nameservers are correctly configured.
Understanding TTL and Caching
Every DNS record has a TTL (Time To Live), shown in seconds in the answer section. This is how long a resolver may cache the record. You can see the TTL in the default output, or explicitly:
dig example.com +ttlid
This adds the TTL to each answer line. A low TTL (like 60 seconds) means the record changes often; a high TTL (86400, one day) means it is stable. When troubleshooting, check the TTL to understand whether a change you made will propagate quickly or slowly.
Common Options and Flags
Several flags are worth memorizing:
+norecurse– sends a query with the recursion-desired bit off. This asks the server to only answer from its cache or authoritative data, not to chase referrals. Useful for testing whether a server is authoritative for a zone.+tcp– forces the query over TCP instead of UDP. Some large responses or certain firewalls require TCP.+dnssec– requests DNSSEC records (RRSIG, DNSKEY, NSEC) along with the answer. Shows whether the zone is signed and whether validation would pass.+time=5and+tries=2– sets the timeout in seconds and the number of retries. Useful for slow or flaky networks.+multiline– formats TXT and other long records across multiple lines, making them readable.
Querying Different Record Types
Beyond A and MX, you will often need:
dig example.com NS– lists the authoritative nameservers for the domain.dig example.com SOA– shows the start of authority record, including the primary nameserver and the serial number. The serial increments on every zone change.dig example.com TXT– shows text records, often used for SPF, DKIM, DMARC, and domain verification.dig example.com CAA– shows which certificate authorities are allowed to issue certificates.dig _dmarc.example.com TXT– a common way to check a DMARC policy.
Reading the Output Sections
The default output can look intimidating. Here is what each section means:
- HEADER – shows the opcode, status (NOERROR, NXDOMAIN, SERVFAIL), and flags (qr, rd, ra, aa).
aameans the answer is authoritative. - QUESTION – echoes your query: the name, class (IN for internet), and type.
- ANSWER – the records that match the question. This is the result you asked for.
- AUTHORITY – the nameservers that are authoritative for the zone, or, for a negative answer, the SOA record that indicates the name does not exist.
- ADDITIONAL – extra records, usually IP addresses for the nameservers listed in the authority section.
The Query time line at the bottom shows how long the round trip took. The SERVER line shows which server answered and on which socket.
Common Problems and Misconceptions
A frequent mistake is expecting dig to show the same result as a web browser. Browsers use their own caches and may use DoH (DNS over HTTPS), so they can resolve differently. Another misconception is that NXDOMAIN means the server is down. It actually means the domain does not exist. If you get SERVFAIL, the server could not answer, which often points to a broken delegation or a DNSSEC validation failure. If you get REFUSED, the server is not configured to answer queries for that zone.
When you change a DNS record, remember that your local resolver and your OS may cache the old value. Use dig @8.8.8.8 to bypass the local cache, and check the TTL to estimate propagation time.
Frequently Asked Questions
How do I install dig on Windows or macOS?
On macOS, dig is preinstalled. On Windows, it is not native; you can use nslookup instead, or install the BIND tools from a package manager like Chocolatey. On Linux, use your package manager: sudo apt install dnsutils (Debian/Ubuntu) or sudo yum install bind-utils (RHEL/CentOS).
Why does dig show a different IP than my browser?
Your browser may use DNS over HTTPS (DoH) to a specific provider, or it may have its own cache. The system resolver used by dig may be different. Also, some domains use geo-DNS, returning different IPs based on the resolver’s location. Compare using dig @8.8.8.8 and dig @1.1.1.1 to see if the answers differ.
What does the +norecurse flag actually do?
It sets the recursion-desired bit to 0 in the query. This tells the server: “Only answer from your own authoritative data or cache; do not go out and ask other servers.” If the server is not authoritative for the zone and has no cached answer, it will return a referral to the next nameservers, not the final answer.
How can I check if DNSSEC is working for a domain?
Use dig example.com +dnssec +noall +answer. If the answer includes an RRSIG record, the zone is signed. To verify the chain, use dig example.com +dnssec +trace and look for DNSKEY records at each level. A SERVFAIL status with +dnssec often indicates a validation failure.
What is the difference between dig and host?
host is a simpler tool that prints a one-line answer for a given name and type. It is fine for quick checks. dig gives you the full DNS message, all flags, and the authority/additional sections, which you need for serious troubleshooting. Both come from the same package.
Can dig query over TCP or HTTPS?
Yes, use +tcp for TCP. For DNS over HTTPS (DoH), dig does not support it natively in most versions; you would use kdig (from Knot DNS) or dog for DoH. For DNS over TLS, kdig also supports @tls:// syntax.