DNS lookups with dig and nslookup: a working cheatsheet

Two commands cover ninety percent of real DNS work: dig example.com +short when you want the answer, and dig @1.1.1.1 example.com when you suspect your resolver is the problem. Everything below is the compact version of what those tools can do — the record types that matter, the reverse direction, and the two debugging moves (compare resolvers, check the TTL) that solve most "DNS is weird" tickets.

Maintained by the ipconfig.io team · Reviewed 1 July 2026

The lookups you'll actually run

dig example.com +short              # A record — the IPv4 address(es)
dig example.com AAAA +short        # IPv6
dig example.com MX +short          # mail servers, with priorities
dig example.com TXT +short         # SPF, verifications, the junk drawer
dig example.com NS +short          # authoritative nameservers
dig www.example.com CNAME +short   # alias target, if it is one
dig -x 203.0.113.42 +short         # reverse: IP → name (PTR)

nslookup equivalents for where dig isn't installed (Windows, minimal containers): nslookup example.com, nslookup -type=MX example.com, nslookup 203.0.113.42 for reverse. Same answers, chattier output.

Two of these connect to your own record: dig -x against your public IP is exactly the reverse DNS shown in the hostname field of curl ipconfig.io/json — and an A lookup resolving a name to an address is step zero of how anything finds anything.

The two debugging moves

Compare resolvers. Your default resolver (usually your ISP's or router's) can be stale, filtered, or lying; a second opinion isolates it:

dig example.com +short              # via your configured resolver
dig @1.1.1.1 example.com +short     # via Cloudflare
dig @8.8.8.8 example.com +short     # via Google

Different answers = resolver-side issue: stale cache after a record change, DNS-level blocking, or a captive portal. Same answers = the record really is what it is; look elsewhere.

Read the TTL. The second column of a full dig answer is seconds-to-live in cache:

example.com.    287    IN    A    93.184.216.34

Run it twice — the TTL counting down means cached; jumping back up means a fresh fetch. This is why DNS changes "take time": every resolver holds the old answer until its TTL runs out. Migrating something? Drop the TTL before the change, not after.

For the rare deep dive, dig +trace example.com walks the delegation from the root servers down — the tool for "is the problem at my registrar, the nameserver, or the resolver?" — and dig example.com ANY is mostly dead (servers refuse it); query types individually.

Frequently asked questions

Basic lookup?dig example.com +short; other types by name (MX, TXT, AAAA); reverse with -x. nslookup where dig is missing.

dig vs nslookup? Same answers — dig for control and scripting, nslookup for ubiquity.

Query a specific server?dig @1.1.1.1 example.com — and comparing resolvers is the fastest DNS diagnosis there is.

The countdown number? TTL — cache seconds remaining. It's why changes propagate slowly and why you lower it before migrations.

Next steps

• What is reverse DNS? — the -x direction in full.
• What is a DNS leak? — when which resolver answers becomes a privacy question.
• Is your IP on a spam blacklist? — DNS lookups as a reputation check.