dig sends one question to a DNS server and prints the answer as it arrived, without the caching an application or the operating system adds. That makes it the tool for finding out what a resolver says, what the authoritative server says, and whether the two agree.
It comes with the BIND tools: sudo apt install bind9-dnsutils on Debian 12 and Ubuntu 24.04, sudo dnf install bind-utils on RHEL 9.
Get the answer only
+short prints the records and nothing else. Without a type, dig asks for the A record.
$ dig +short example.com192.0.2.10$ dig +short example.com AAAA2001:db8::10$ dig +short example.com MX10 mail.example.com.
An empty result means there’s no record of that type. To tell an empty answer from a name that doesn’t exist, read the full output.
Read the full output
$ dig example.com# the version banner and the EDNS section are left out;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41536;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION:;example.com. IN A ;; ANSWER SECTION:example.com. 2841 IN A 192.0.2.10 ;; Query time: 12 msec;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP);; WHEN: Sat Oct 24 14:02:11 CEST 2026;; MSG SIZE rcvd: 56
| Part | What it tells you |
|---|---|
status | Whether the lookup worked. The table below lists four common ones. |
flags | qr marks a response, rd means you asked for recursion, ra that the server offers it, and aa that it’s authoritative for the name |
ANSWER SECTION | One record per line: name, TTL in seconds, class, type, data. |
2841 | The TTL. On a resolver it counts down from the value in the zone; at 0 the resolver asks again. |
SERVER | The server that answered. Without @, it’s the first nameserver in /etc/resolv.conf. |
| Status | Means |
|---|---|
NOERROR | The name exists. With an empty ANSWER section, it has no record of the type you asked for. |
NXDOMAIN | The name doesn’t exist, for any type. |
SERVFAIL | The resolver couldn’t get an answer: the authoritative servers didn’t respond, or DNSSEC validation failed. |
REFUSED | The server won’t answer you. An authoritative server asked about a zone it doesn’t host replies this way, and so does a resolver that only serves its own network. |
Ask for a record type
| Type | Holds | Ask with |
|---|---|---|
| A | An IPv4 address | dig +short example.com A |
| AAAA | An IPv6 address | dig +short example.com AAAA |
| CNAME | Another name this one is an alias for | dig +short www.example.com CNAME |
| MX | The mail servers, with their priority | dig +short example.com MX |
| TXT | Text: SPF, DKIM keys, verification tokens | dig +short example.com TXT |
| NS | The authoritative name servers | dig +short example.com NS |
| SOA | The zone’s serial number and timers | dig +short example.com SOA |
| CAA | Which CAs may issue certificates | dig +short example.com CAA |
Ask a specific server
Put the server after @. Asking two public resolvers shows whether a change has reached the caches outside your network.
$ dig @1.1.1.1 +short example.com192.0.2.10$ dig @9.9.9.9 +short example.com192.0.2.10
Ask the authoritative server
A resolver answers from its cache. The authoritative server answers from the zone itself, so it shows what the record is, not what it was when the resolver last asked. Find the name servers, then ask one of them with recursion turned off:
$ dig +short example.com NSns1.example.net.ns2.example.net.$ dig @ns1.example.net example.com A +norecurse# trimmed to the flags and the answer;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1example.com. 3600 IN A 192.0.2.10
The aa flag confirms the answer came from the zone. The TTL is the full value set there, 3600 seconds. The resolver above showed 2841, so it fetched the record 759 seconds earlier and keeps it for another 2841 seconds. If the authoritative server already has a new address and the resolver still returns the old one, the change is made and the cache hasn’t expired yet. Lower the TTL before you move a site explains how to plan around that.
Follow the delegation with +trace
+trace starts at the root servers and asks each level in turn, the way a resolver does on an empty cache. It shows which name servers the parent zone hands out for your domain, which is what to check after you change name servers at the registrar.
$ dig +trace example.com# trimmed to one line per level. 518400 IN NS a.root-servers.net.;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 4 mscom. 172800 IN NS a.gtld-servers.net.;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 20 msexample.com. 172800 IN NS ns1.example.net.;; Received 380 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 msexample.com. 3600 IN A 192.0.2.10;; Received 56 bytes from 198.51.100.53#53(ns1.example.net) in 16 ms
The highlighted line comes from the .com servers: those are the name servers the world is sent to. If it still lists the old ones after a change at the registrar, the registry hasn’t published it yet.
Look up a name from an address
-x turns an address into the PTR query for it. Reverse records are served by whoever holds the address range, usually the hosting provider, not by the DNS of the domain the name belongs to.
$ dig +short -x 192.0.2.10web-01.example.com.$ dig +short -x 2001:db8::10web-01.example.com.
Mail servers check that the PTR of a sending address resolves back to the same address. If yours doesn’t, set the PTR where the address is managed: at your provider, or in the console of the hosting you rent it from.
Last checked on 24 October 2026 against BIND 9.18 dig (Debian 12, Ubuntu 24.04) and bind-utils 9.16 (RHEL 9). If a step doesn’t match what you see, contact us with the command and what it printed.