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 |