Troubleshooting DNS with dig and nslookup

When a domain will not resolve, points to the wrong server, or emails bounce, two command line tools tell you exactly what the DNS is returning: dig and nslookup. Both query DNS directly, so you see the real answer instead of a cached guess from your browser. This guide shows the practical commands for looking up A, MX, TXT, and other records, and how to read the output.

dig vs nslookup: which to use

dig (Domain Information Groper) is the preferred tool on Linux and macOS. It is scriptable, precise, and shows the full response including TTL and the authoritative section. nslookup ships with Windows and older systems and is fine for quick checks. If both are available, use dig.

Looking up records with dig

The basic pattern is dig [name] [type]. A few common queries:

1. Find the IPv4 address behind a domain:

   dig example.com A

2. Check mail routing (where email is delivered):

   dig example.com MX

3. Read TXT records such as SPF and DKIM:

   dig example.com TXT
   dig default._domainkey.example.com TXT

4. Trim the noise and print only the answer:

   dig +short example.com A

5. Query a specific nameserver instead of your local resolver:

   dig @8.8.8.8 example.com A

To see the full delegation path from the root servers down, use dig +trace example.com. This is the fastest way to confirm which nameservers are actually authoritative for your zone.

Reading the output

In a full dig response, focus on three areas. The status: NOERROR line in the header means the query succeeded; NXDOMAIN means the name does not exist. The ANSWER SECTION lists each record with its type, TTL in seconds, and value. A high TTL (for example 3600) means resolvers will cache that answer for an hour, which is why a recent change may not be visible yet.

Using nslookup

For a quick check on any system, the same lookups look like this:

nslookup example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8

The trailing server address forces nslookup to ask that resolver directly, which helps you tell propagation delays apart from a genuine misconfiguration.

Common troubleshooting patterns

• Site loads on the old server: compare dig +short yourdomain.com A against your new IP. If they differ, the record or its TTL has not updated everywhere yet.
• Email bouncing: confirm the MX and SPF records with dig MX and dig TXT. A missing or duplicate SPF record is a frequent cause.
• Nameserver mismatch: run dig +trace and verify the authoritative servers match the ones set at your registrar.

On our platform each site sits on a dedicated Class C IP, so a clean A record makes footprint control and diagnostics straightforward. For a deeper look at record types, see our DNS and IP management guides, and if a lookup shows something you cannot explain, our team can help through contact us. For the formal definitions of DNS terminology, the IETF maintains RFC 9499.