Mental model
Your laptop wants to load www.packetmentor.com. The browser has no idea what IP that is. So it asks a resolver (usually your ISP’s, or 8.8.8.8, or 1.1.1.1) to find out.
The resolver doesn’t know either — but it knows where to start asking. It walks a chain:
- “Hello root, who runs .com?” Root answers: “Ask the .com TLD servers.”
- “Hello .com, who runs packetmentor.com?” TLD answers: “Ask packetmentor.com’s authoritative server.”
- “Hello packetmentor.com auth, what’s the IP of www?” Auth answers: “203.0.113.42.”
The resolver returns just the final answer to your laptop. It also caches the answer for the duration specified by the record’s TTL (Time To Live) — so the next person asking gets the answer instantly without walking the chain again.
Record types you need to know
| Type | Purpose | Example |
|---|---|---|
| A | Name → IPv4 address | www.example.com → 203.0.113.42 |
| AAAA | Name → IPv6 address | www.example.com → 2001:db8::1 |
| CNAME | Alias to another name | www → example.com. |
| MX | Mail server for the domain | example.com → mail.example.com (priority 10) |
| NS | Authoritative nameserver for the zone | example.com → ns1.example.com |
| PTR | IP → name (reverse DNS) | 42.113.0.203.in-addr.arpa → www.example.com |
| TXT | Anything text (SPF, DKIM, domain verification) | v=spf1 ... |
| SOA | Start of Authority — zone metadata | refresh, retry, expire, TTL |
For CCNA: A and AAAA are by far the most asked. Understand CNAME (it’s a pointer, not a copy) and MX (it’s what mail servers query to deliver email).
TTL — the caching contract
Every DNS record has a TTL (in seconds). When a resolver caches an answer, it holds it for that long before re-asking.
| TTL | When to use |
|---|---|
| 300 (5 min) | Aggressive — for records you might change soon |
| 3600 (1 hr) | Normal default |
| 86400 (24 hr) | Stable records that rarely change |
Migration tip: before changing an A record’s IP, lower the TTL to 300 a day in advance. Wait for the old TTL to expire everywhere. Then change. New IP propagates in 5 min instead of a day.
Commands
Query DNS from a Cisco router
R1# nslookup www.packetmentor.com
R1# show host
Configure DNS resolver settings
R1(config)# ip name-server 8.8.8.8 1.1.1.1
R1(config)# ip domain-lookup
R1(config)# ip domain-name corp.local
ip domain-lookup is on by default. The annoying side-effect: if you mistype a command, the router tries to DNS-resolve it as a hostname, which times out for ~30 seconds before giving you the prompt back. Most engineers disable it:
R1(config)# no ip domain-lookup
Configure a Cisco IOS DNS server (rare in production, but exam-relevant)
R1(config)# ip dns server
R1(config)# ip host www.corp.local 10.0.0.50
DNS as a troubleshooting layer
When users say “the internet is down”, the issue is often DNS — not the network. Ping fails by hostname but succeeds by IP? DNS problem. The classic flow:
$ ping www.example.com ← fails with "unknown host"
$ ping 203.0.113.42 ← works
That’s a DNS failure, not a network failure. Common culprits: ISP DNS server down, local cache poisoning, misconfigured resolver, network adapter has no DNS server assigned.
Common mistakes
No reverse DNS for an outbound mail server. Many mail receivers reject mail from IPs without a matching PTR record. If you run a mail server, set up the PTR record at your ISP for that IP.
TTL too long during migration. A 7-day TTL means a week of half the internet seeing your old IP after a change. Lower TTLs before migration, not after.
CNAME at the apex. RFC says you can’t have a CNAME on the apex (root domain) — only on subdomains. Most modern DNS providers offer “ALIAS” or “ANAME” pseudo-records to work around this.
Forgetting
ip domain-lookupis on by default. Mistype a command, wait 30 seconds, curse the router. Always disable on lab/admin routers.Putting unauthorized DNS servers in your name-server list. A typo’d IP could send queries to a malicious server logging everything you look up. Stick to well-known public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) or your own internal one.
Confusing recursive and authoritative. Recursive resolvers do the legwork. Authoritative servers answer for the zones they own. Most public servers do both, but they’re conceptually distinct.
Lab to try tonight
- From your laptop, run
dig www.cisco.com(ornslookupon Windows). Note the answer + TTL. - Run it again immediately — the second response is from cache, should be much faster.
- Run
dig +trace www.cisco.com— watch the recursive walk happen step-by-step from root to TLD to authoritative. - On a Cisco router, configure
ip name-server 1.1.1.1. Then runping www.cisco.comand verify DNS resolution works. - Disable
ip domain-lookup. Mistype a command. Confirm you no longer wait 30s for the prompt. - Bonus: change the TTL on a test domain you control. Watch propagation time difference.
Cheat strip
| Concept | Plain English |
|---|---|
| Resolver | The server that walks the query chain on the client’s behalf |
| Authoritative server | The server that owns the record (the “source of truth”) |
| Root → TLD → Auth | The three steps of a recursive lookup |
| TTL | How long answers stay cached. Lower = faster propagation, more lookups. |
| A / AAAA | IPv4 / IPv6 address records |
| CNAME | Alias (pointer) to another name |
| MX | Mail server for the domain |
| PTR | Reverse lookup — IP to name |
no ip domain-lookup | Disables DNS on the router CLI to avoid mistype delays |