dig Command Cheatsheet: Query DNS from the Terminal (2026)

dig is your Swiss Army knife for DNS troubleshooting, letting you ask precise questions to DNS servers right from your terminal.

Let’s see it in action. Imagine you’re trying to figure out the IP address for example.com.

dig example.com

This basic query asks for the A record (the IPv4 address) by default. The output will look something like this:

; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       93.184.216.34

;; Query time: 45 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 20 10:00:00 UTC 2023
;; MSG SIZE  rcvd: 55

The key parts here are:

• QUESTION SECTION: What you asked for. example.com. IN A means "give me the IPv4 address for example.com."
• ANSWER SECTION: The direct answer. example.com. 86400 IN A 93.184.216.34 tells you the IP is 93.184.216.34 and that this record is valid for 86400 seconds (24 hours).
• SERVER: Which DNS server answered your query. In this case, it’s a local resolver at 127.0.0.53.

dig is powerful because you can specify exactly what you want to query. You can ask for different record types:

• MX (Mail Exchanger): To find mail servers for a domain.

  dig gmail.com MX
  

  This will show you which servers handle email for gmail.com, along with their preference order.

• NS (Name Server): To see which servers are authoritative for a domain.

  dig google.com NS
  

  This lists the name servers responsible for google.com’s DNS records.

• TXT (Text): Often used for verification (like SPF or DKIM records).

  dig example.com TXT
  

• CNAME (Canonical Name): To resolve aliases.

  dig www.example.com CNAME
  

You can also query specific DNS servers, which is invaluable for diagnosing why a particular server might be slow or giving incorrect answers. For instance, to query Google’s public DNS server (8.8.8.8) for example.com’s A record:

dig @8.8.8.8 example.com

This helps isolate whether the problem is with your local DNS resolver or a remote authoritative server.

The +trace option is incredibly useful for understanding the full path a DNS query takes. It shows you the delegation from the root servers down to the authoritative servers for your domain.

dig +trace example.com

This will show you queries to ., then to the TLD servers for .com, and finally to the authoritative name servers for example.com. Each step reveals which server is being queried and what answer it provided.

The +short option strips away all the extra detail, giving you just the answer itself. This is perfect for scripting or quickly grabbing a single piece of information.

dig +short www.google.com A

This might output just 142.250.180.196.

When you want to see all the records for a domain, not just a specific type, use ANY. Be aware that ANY queries are often blocked or rate-limited by servers for performance and security reasons, but they can be useful for a broad overview.

dig example.com ANY

The true power of dig lies in its ability to mimic the DNS resolution process precisely. When you specify a server with @, you’re not asking your system’s default resolver to find the answer; you’re directly asking that specific server. This means if dig @8.8.8.8 example.com returns an IP address, but dig example.com (using your local resolver) doesn’t, the problem is likely with your local resolver’s configuration, cache, or its ability to reach 8.8.8.8.

Beyond basic lookups, dig can also be used to query specific record classes (though IN for Internet is almost always what you want) and to control the query behavior with various flags. For example, disabling recursion with +norecurse forces dig to only ask for information that the queried server directly knows or is authoritative for, which is fundamental for understanding delegation.

The +noall +answer combination is a common way to get just the answer section, similar to +short but often more structured if multiple records are returned.

dig +noall +answer www.example.com A

Understanding the flags field in the header (qr for query response, rd for recursion desired, ra for recursion available) is key to debugging why a query might not be returning what you expect, especially when dealing with client-side recursion issues.

The next step is often understanding how dig interacts with different DNS record types beyond the common ones, such as SOA (Start of Authority) for zone administration details.