Seeing It Live: nslookup and dig
In one line: 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.
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
Running it is the fastest way to make the hierarchy concrete: you can watch a query that a resolver normally hides, one delegation at a time.
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.