Verify DNS Records with dig and nslookup (2026)

DNS is the phonebook of the internet, but sometimes the entries get garbled, leading to "can’t find server" errors.

Let’s see what’s actually happening when you query for a DNS record. Imagine you want to find the IP address for example.com.

# This is a live query, so the output will vary.
dig example.com A

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> example.com A
;; 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: 65494
;; QUESTION SECTION:
;example.com.                   IN      A

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

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon May 06 10:00:00 UTC 2024
;; MSG SIZE  rcvd: 69

Here, dig asks a DNS resolver (in this case, 127.0.0.53, likely your local system resolver) for the A record (IPv4 address) of example.com. The resolver, if it knows the answer, returns it directly. If not, it goes on a journey to find it. The ANSWER SECTION shows example.com resolves to 93.184.216.34 with a Time To Live (TTL) of 300 seconds.

The problem dig and nslookup solve is that the DNS resolution process can be a black box. You type a hostname, and something happens. These tools peel back the curtain, showing you each step of that something and allowing you to pinpoint where things go wrong. They are your primary tools for diagnosing why a hostname isn’t resolving to the expected IP address, or why a service isn’t reachable.

Let’s trace the path for example.com if your local resolver doesn’t have it cached.

Root Servers: Your resolver asks a root server (e.g., a.root-servers.net) "Who is authoritative for .com?".
TLD Servers: The root server replies with the addresses of the .com Top-Level Domain (TLD) servers. Your resolver then asks a .com TLD server "Who is authoritative for example.com?".
Authoritative Nameservers: The .com TLD server replies with the addresses of the authoritative nameservers for example.com (e.g., ns1.example.com, ns2.example.com). Your resolver then asks one of these authoritative nameservers "What is the A record for example.com?".
Final Answer: The authoritative nameserver for example.com returns the IP address 93.184.216.34.

This entire process, called recursive resolution, is usually handled by your ISP’s DNS servers or public resolvers like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. dig and nslookup can simulate this by querying these servers directly, or they can be configured to query specific authoritative nameservers to test individual zones.

The most surprising thing is how much control you have over the path of resolution. By default, dig and nslookup will use your system’s configured resolver. But you can tell them to query any DNS server on the internet. This allows you to bypass local caching issues or network intermediaries and directly test if a specific authoritative nameserver is providing the correct answer. For example, to ask Google’s public DNS server for the A record of example.com:

dig @8.8.8.8 example.com A

This is crucial for debugging when you suspect your local network or ISP’s DNS might be the culprit. You’re not just asking "what’s the IP?", you’re asking "what does this specific server say the IP is?".

This direct querying capability is also how you verify that your own authoritative nameservers are correctly configured. If you’ve just updated your DNS records at your domain registrar or DNS hosting provider, you can use dig to query your own authoritative nameserver directly to confirm the changes have propagated and are being served correctly. For instance, if ns1.mydomain.com is your authoritative server:

dig @ns1.mydomain.com mydomain.com MX

This command asks ns1.mydomain.com for the MX (Mail Exchanger) records for mydomain.com. If the output doesn’t match what you expect, the problem lies with your authoritative server’s configuration, not with the recursive resolvers.

The next step in DNS mastery is understanding how different record types (like MX, CNAME, TXT, SRV) are used and how to query for them specifically.