Search... ⌘ K
Get Started Contact Sales

How to Use dig

Last updated

When you are trying to troubleshoot DNS issues, dig (domain information groper) is one of the most valuable tools. If you are new to dig, start with What Is dig? for an introduction. For a quick reference of dig syntax and options, see the dig Reference Guide.

From the dig manual:

dig (domain information groper) is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried.

An example, asking your configured resolver for the A record of example.com:

$ dig example.com

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

;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		3600	IN	A	192.0.2.1

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Oct 14 11:17:13 UTC 2026
;; MSG SIZE  rcvd: 56

What this output tells you

  • Line one shows the dig version that was used and the domain queried.
  • Then you see any global dig options, followed by packet details in human-readable form.
  • NOERROR indicates the response was returned without an error. NXDOMAIN would mean the name does not exist.
  • The line ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 provides various details about the DNS packet (RFC 1035 has an in-depth explanation of the content of a DNS packet). The ra flag means the server offers recursion, so this answer came from a resolver.
  • The QUESTION section shows the question that was sent: “I want A records for example.com.”
  • The ANSWER section shows the reply: “example.com has one A record with the content 192.0.2.1, and this answer can be cached for 3600 seconds.”
  • The footer shows how long the query took, which server was used, when the query ran, and the packet size.

dig at a name server

The first example uses the resolver configured on your computer, which in that case was the Google public resolver at 8.8.8.8. A resolver may answer from its cache.

To ask an authoritative name server directly, put its name after @. This shows the current value with no caching in between:

$ dig @ns1.dnsimple-edge.com example.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35081
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
example.com.		3600	IN	A	192.0.2.1

;; SERVER: 199.247.152.53#53(ns1.dnsimple-edge.com) (UDP)

The aa (authoritative answer) flag shows the answer came from a name server that hosts the zone. The warning about recursion is normal: authoritative name servers do not resolve other domains.

+trace

Another useful option is +trace. Instead of asking a resolver, dig follows the delegation itself: it starts at the root name servers and works down the domain name hierarchy to the authoritative name servers. This example traces a domain hosted at DNSimple:

$ dig +trace example.com

.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
(more root name servers)
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 20 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
(more .com name servers)
;; Received 1170 bytes from 192.112.36.4#53(g.root-servers.net) in 30 ms

example.com.		172800	IN	NS	ns1.dnsimple-edge.com.
example.com.		172800	IN	NS	ns2.dnsimple-edge.net.
example.com.		172800	IN	NS	ns3.dnsimple-edge.io.
example.com.		172800	IN	NS	ns4.dnsimple-edge.org.
;; Received 300 bytes from 192.55.83.30#53(m.gtld-servers.net) in 25 ms

example.com.		3600	IN	A	192.0.2.1
;; Received 56 bytes from 199.247.154.53#53(ns3.dnsimple-edge.io) in 12 ms

Each block is one step of the delegation:

  1. dig asks your resolver (8.8.8.8 here) for the list of root name servers.
  2. It asks one of the root servers (g.root-servers.net), which replies with the name servers for .com.
  3. It asks one of the .com servers (m.gtld-servers.net), which replies with the name servers the domain is delegated to: DNSimple’s four name servers.
  4. It asks one of those (ns3.dnsimple-edge.io), which returns the authoritative answer.

If the third block lists name servers other than DNSimple’s, the domain is not delegated to DNSimple at the registry.

Additional common lookups

Querying AAAA (IPv6) records

To look up a specific record type, add the type to the command. The ANSWER section contains the fully-qualified domain name (FQDN), the remaining time-to-live (TTL), and the IPv6 address:

$ dig AAAA ns1.dnsimple-edge.com +noall +answer
ns1.dnsimple-edge.com.	1795	IN	AAAA	2620:111:8004::53

The +noall +answer options hide everything except the answer section.

Querying CNAME records

The ANSWER section contains the fully-qualified domain name (FQDN), the remaining time-to-live (TTL), and the hostname the CNAME points to:

$ dig CNAME www.example.com +noall +answer
www.example.com.	3599	IN	CNAME	example.com.

For MX records, see Query MX Records.

Digging deeper

To dig even deeper into dig, open a console and type dig -h for the list of supported options, or man dig for more in-depth details about dig and how it functions.

Troubleshooting DNS issues

If you are experiencing DNS resolution problems, see Troubleshoot Record Resolution Issues or Troubleshoot Domain Resolution Issues for comprehensive troubleshooting guidance. You may also want to check your DNS cache if you are not seeing recent DNS changes.

Have more questions?

If you have additional questions or need any assistance troubleshooting your DNS, just contact support, and we will be happy to help. You can also read more about DNS hosting at DNSimple.