Seeing It Live: nslookup and dig

Why this matters: everything in this chapter is observable from your terminal in about thirty seconds. Running these commands turns the hierarchy, caching, TTL, and round robin from things you memorized into things you have watched happen.

Key takeaway

Two commands show you the whole system: nslookup for a quick answer, dig for the full record with TTL and timing. Run them on any domain and you can read the cache state, the record's freshness, and the load-balancing strategy directly off the output.

Try it now

nslookup www.google.com
dig www.google.com

Reading the `nslookup` output

Server:      2406:7400:a:10::2
Address:     2406:7400:a:10::2#53

Non-authoritative answer:
Name:    www.google.com
Address: 142.251.156.119
Name:    www.google.com
Address: 142.251.151.119
Name:    www.google.com
Address: 142.251.150.119
Name:    www.google.com
Address: 142.251.152.119

Two things to read here:

"Non-authoritative answer" — this indicates the response came from a cache, such as your ISP or university resolver, rather than directly from the authoritative name servers. This single line is the caching lesson made visible: your query never reached Google's servers at all.

Multiple addresses, and their order. Run the command several times and the list may come back in a different order. That is DNS round robin, the load-balancing technique from the previous lesson. Note also that the set of addresses can differ between runs — large services return a subset from a much larger pool.

Reading the `dig` output

dig shows considerably more:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41570
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     256     IN  A   142.251.150.119
www.google.com.     256     IN  A   142.251.152.119
www.google.com.     256     IN  A   142.251.157.119
www.google.com.     256     IN  A   142.251.155.119
...

;; Query time: 4 msec
;; SERVER: 2406:7400:a:10::2#53

Field	What it tells you
ANSWER SECTION	The records returned — here 8 A records, the address list DNS hands the client
The number after the name (256)	TTL in seconds — how long this record may still be cached
IN A	Class INternet, record type A — the record types from Lesson 2
Query time	Time to receive a response. Single-digit ms means a cache hit; tens or hundreds means a real walk
SERVER	Which resolver answered you
status: NOERROR	The lookup succeeded. NXDOMAIN here would mean the name does not exist

A TTL of 300 would mean the resolver caches this record for five minutes (300 / 60) before refreshing it. A query time of 4 msec is far too fast to have walked the hierarchy — that answer came from a nearby cache.

Watch the TTL count down

This is the most convincing demonstration in the chapter. Run dig on the same name twice, a little apart:

dig www.google.com +noall +answer

www.google.com.     256     IN  A   142.251.155.119     <- first run

...a few minutes later...

www.google.com.      96     IN  A   142.251.155.119     <- same record, lower TTL

The TTL decreases between runs. That is the resolver telling you exactly how much life its cached copy has left — it is counting down from the original value toward zero, at which point it will discard the record and fetch it again.

Walking the hierarchy yourself

dig +trace performs the iterative resolution from Lesson 4 explicitly, showing every referral:

dig +trace www.google.com

.    600  IN  NS  a.root-servers.net.
.    600  IN  NS  b.root-servers.net.
...
.    600  IN  NS  m.root-servers.net.

That list is the 13 logical root servers, labeled a through m, exactly as described in Lesson 6. Let the trace continue and you will see it descend to the .com TLD servers, then to Google's authoritative servers, then to the final A record — the full root → TLD → authoritative walk, one referral at a time.

Useful variations

Command	What it shows
`dig example.com MX`	Mail records for the domain
`dig example.com NS`	The authoritative name servers
`dig example.com CNAME`	Whether the name is an alias
`dig +trace example.com`	The full iterative walk down the hierarchy
`dig +short example.com`	Just the answer, nothing else

Try several services and compare their TTL values and query times. Providers that expect to move traffic keep TTLs low; stable infrastructure records run for hours.

What to look for on any domain

Observation	What it implies
Very short TTL (30-60 s)	They expect to move traffic — active failover or a migration in progress
Long TTL (hours)	Stable infrastructure; changes will propagate slowly
Many A records	Round robin or a large edge fleet
CNAME to a provider's hostname	A CDN or managed service sits in front
Query time under 10 ms	Cache hit — the hierarchy was never touched
Different answers from different networks	Geolocation or latency-based routing is in play

Key takeaway

You can read a company's DNS strategy off two commands. TTL reveals how fast they intend to change things, record count reveals their balancing approach, and a CNAME reveals whose infrastructure is really in front.

Interview signal by level

Level	What a strong answer sounds like
L4	Knows `nslookup` resolves a name.
L5	Reads the output: "non-authoritative means it came from a cache, and the TTL tells me how long it's held."
Staff+	Uses it diagnostically: "I'd `dig` from the affected region to see which answer that resolver returns and how much TTL is left — that tells me whether users are stuck on a stale record and roughly how long until they converge."

Next: designing the whole system from scratch.