Checking DNS with dig and nslookup: a practical guide

When a site will not load, email goes missing or a new DNS record "is not working yet", the first question is always the same: what does the domain actually point to right now? Two classic tools answer that precisely, dig and nslookup. Both send a query straight to a DNS server and print the raw answer. Here is how to use them, how to read the output and how to spot the most common problems.

Getting the tools

nslookup ships with Windows, macOS and most Linux systems. dig comes with macOS and is a separate package on Linux; on Windows you can get it from the Windows build of BIND or use it inside WSL. dig gives fuller, more structured output, which is why administrators prefer it, while nslookup is handy for a quick check on any Windows PC.

# Debian / Ubuntu
sudo apt install dnsutils

# RHEL / AlmaLinux / Rocky
sudo dnf install bind-utils

Reading a dig answer

Without a record type, dig asks for an A record:

; <<>> DiG 9.18.28 <<>> sizningdomen.uz A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;sizningdomen.uz.            IN    A

;; ANSWER SECTION:
sizningdomen.uz.     3600    IN    A    203.0.113.10

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

Three lines matter most. status is the result: NOERROR means success, NXDOMAIN means the name does not exist, SERVFAIL means the server could not answer. The ANSWER SECTION holds the record, and the second column (3600 here) is the TTL in seconds. SERVER shows who answered, in this case the home router. In flags, aa appears only when you query the domain's own nameserver, confirming an authoritative rather than cached answer.

Everyday dig commands

+short prints just the result; +noall +answer keeps the TTL. The last command is a reverse (PTR) lookup, important for mail servers because receivers check the sender IP's PTR record:

dig sizningdomen.uz A +short
dig sizningdomen.uz MX +short
dig sizningdomen.uz TXT +short
dig sizningdomen.uz NS +short
dig -x 203.0.113.10 +short

Use @ to ask a specific server and compare resolvers, and +trace to follow the delegation from the root through .uz to the domain's nameserver and see where it breaks:

dig @8.8.8.8 sizningdomen.uz A +short
dig @<nameserver-name> sizningdomen.uz A +norec
dig +trace sizningdomen.uz

nslookup on Windows

nslookup sets the type with -type= and takes the server after the name. "Non-authoritative answer" is not an error; it just means the reply came from a resolver cache. Run it without arguments for interactive mode and type set type=mx followed by the domain to check several records in a row.

nslookup -type=mx sizningdomen.uz
nslookup -type=txt sizningdomen.uz
nslookup sizningdomen.uz 8.8.8.8

Example: a school's email stops arriving

A private school in Tashkent connected corporate email, but messages from parents were not arriving. dig sizningdomen.uz MX +short showed the MX still pointed to the old mail service. After fixing it, a TXT lookup revealed the SPF record did not include the new mail server. With both corrected, the administrator queried the domain's nameserver first and then public resolvers to watch the new values spread.

Interpreting results

If the nameserver returns the new value but a public resolver returns the old one, it is caching; wait for the TTL. If the nameserver itself returns the old value, the change was not saved or went into the wrong zone. NXDOMAIN can mean a typo or a domain that is no longer delegated, for example after expiry. SERVFAIL often points to an unreachable nameserver or a DNSSEC problem; if adding +cd makes the answer appear, check that the DS record matches the zone's keys. sayt.uz customers edit DNS in the cabinet, and these commands let them verify every change independently.