Help Center / domains

Using dig and nslookup to check DNS

Using dig and nslookup to Check DNS

dig and nslookup are free command-line tools that ask the DNS system questions directly, without a browser in the way. They answer questions like: What IP does my domain point to? Did my DNS change go live? Which nameservers is my domain actually using? This guide starts from zero and works up to the advanced flags support engineers use daily.

Which tool should you use?

Rule of thumb: nslookup is fine for "what does this record say right now". dig is the better tool the moment something is wrong, because it shows the full DNS response including status codes and TTLs.

Installing dig where it is missing:

• Windows: install BIND tools or use WSL (sudo apt install dnsutils)
• Debian/Ubuntu: sudo apt install dnsutils
• RHEL/Fedora/Alma/Rocky: sudo dnf install bind-utils

Beginner: Your First Lookup

Both commands take a domain name. With no other options they return the domain's A record (its IPv4 address):

nslookup example.com
dig example.com

nslookup's answer is short:

Server:  1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
Name:    example.com
Address: 96.7.128.175

• Server is the DNS resolver that answered you (your router, ISP, or a public resolver), not your domain's nameserver.
• Non-authoritative answer means the answer came from that resolver's cache, not straight from the domain's own nameservers. That is normal.

Reading dig Output

dig prints more, in labeled sections:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31337
;; QUESTION SECTION:
;example.com.            IN  A

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

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

Want just the answer, nothing else? Add +short:

dig example.com +short
96.7.128.175

Looking Up Specific Record Types

DNS holds more than IP addresses. Pass the record type after the domain:

Two you will use constantly:

# Where does mail for this domain go?
dig example.com MX +short
10 mail.example.com.

# Is my SPF / site-verification TXT record live?
dig example.com TXT +short
"v=spf1 include:_spf.example.com ~all"

The number in front of an MX target (10) is its priority - lower is tried first.

Intermediate: Ask a Specific DNS Server

By default both tools ask whatever resolver your system uses. You can ask any server directly - this is the single most useful trick for checking DNS propagation:

# Ask Google's public resolver
dig @8.8.8.8 example.com

# Ask Cloudflare's
dig @1.1.1.1 example.com

# Ask the domain's own (authoritative) nameserver
dig @ns1.osir.com example.com

With nslookup, the server goes last: nslookup example.com 8.8.8.8

Propagation check in two commands. After changing a record, ask the authoritative nameserver first, then a public resolver:

1. dig @ns1.osir.com example.com +short - shows the new value immediately. If it does not, the record was not saved correctly; recheck your DNS dashboard.
2. dig @8.8.8.8 example.com +short - may show the old value until its cached copy expires (up to the old record's TTL). That is not a fault; it is caching working as designed.

There is no way to force other people's resolvers to forget a cached record, which is why lowering the TTL before a planned change is the professional move.

Intermediate: Reverse Lookups

A reverse lookup asks "what name belongs to this IP?" - useful for identifying a server in your logs:

dig -x 96.7.128.175
nslookup 96.7.128.175

This queries the IP's PTR record. Note that PTR records are controlled by whoever owns the IP block (usually the hosting provider), not by your domain's DNS zone.

Intermediate: nslookup Interactive Mode

Run nslookup with no arguments to enter interactive mode - handy for checking several records without retyping:

> server ns1.osir.com     # switch to a specific server
> set type=MX             # switch record type
> example.com             # query
> set type=TXT
> example.com
> exit

Advanced: Follow the Full Resolution Path

dig +trace ignores caches entirely and walks the DNS tree the way a resolver does on a cold start: root servers, then the TLD's servers, then your domain's nameservers:

dig +trace example.com

Read it bottom-up when debugging: the last hop shows which nameserver gave the final answer. If the trace dies at the TLD level, your delegation (the NS records set at the registrar) is broken - the registry is not pointing at the nameservers you think it is. If it dies at the last hop, the nameservers are delegated correctly but are not answering for the zone.

Advanced: Compare Serials to Catch Out-of-Sync Nameservers

Every zone has an SOA serial number that increments on each change. If your nameservers disagree, some users get old answers:

dig @ns1.osir.com example.com SOA +short
dig @ns3.osir.com example.com SOA +short

The third field in each answer is the serial. They should match. A lagging secondary explains "it works for some people but not others" better than almost anything else.

Advanced: Useful dig Flags

# Clean answer with TTL - the everyday workhorse
dig example.com A +noall +answer
example.com.   3600   IN   A   96.7.128.175

Status Codes: What the Server Told You

The status: field in dig's header is the first thing to read when something fails:

The NOERROR-but-empty case trips people up the most: dig sub.example.com A returning NOERROR with no ANSWER section means sub.example.com exists (perhaps as an MX or TXT) but has no A record.

Troubleshooting Recipes

Managing the Records Themselves

These tools read DNS; to change it, use your dashboard's DNS editor. Domains registered with us use ns1.osir.com and ns3.osir.com by default, so dig @ns1.osir.com yourdomain.com always shows you the truth we are publishing. For the bigger picture of how nameservers, glue records, and TTLs fit together, read DNS and Nameservers Explained.