DNS: Domain Name System

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:

1. “Hello root, who runs .com?” Root answers: “Ask the .com TLD servers.”
2. “Hello .com, who runs packetmentor.com?” TLD answers: “Ask packetmentor.com’s authoritative server.”
3. “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

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.

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.

Diagnosing DNS record problems (CCNA v2.0 4.4)

Most DNS tickets come down to one record that is wrong, missing, or pointing at the wrong place. Ask for the specific record type instead of doing a plain lookup, and the answer (or the error) tells you which record to fix.

What breaks when each record is wrong

On Windows PowerShell, Resolve-DnsName -Name example.com -Type MX returns the same MX data as objects you can filter or export.

Reading the error

• NXDOMAIN (nslookup says “Non-existent domain”): the name does not exist. The server answered, so the network path is fine. Check spelling and whether the record was ever created in the right zone.
• NOERROR with an empty answer: the name exists but has no record of the type you asked for. Typical for a missing AAAA or MX.
• SERVFAIL (nslookup says “Server failure”): the server could not process the query. Look at the zone’s NS records and whether those authoritative servers are reachable and answering.
• Timeout (nslookup says “timed out”): no reply at all. That’s reachability, not records: wrong DNS server on the client, or an ACL or firewall blocking port 53.

Worked example: mail isn’t arriving

Outside senders report that mail to example.com bounces. Start with the MX record:

C:\> nslookup -type=mx example.com
example.com     MX preference = 10, mail exchanger = mail.example.com

Now look up the name the MX points to with dig mail.example.com A. Two faults show up here in real networks:

1. The MX target is a CNAME. RFC 2181 says the name in an MX record must not be an alias. Some senders cope, others don’t. Point the MX at a hostname that has its own A (and AAAA) record.
2. The MX target resolves, but to the wrong host. After a migration the A record still says 192.0.2.25, the old server. Update the A record to the new server’s address, then allow the old TTL to expire before you call it fixed.

Common mistakes

1. 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.

2. 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.

3. 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.

4. Forgetting ip domain-lookup is on by default. Mistype a command, wait 30 seconds, curse the router. Always disable on lab/admin routers.

5. 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.

6. 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

1. From your laptop, run dig www.cisco.com (or nslookup on Windows). Note the answer + TTL.
2. Run it again immediately: the second response is from cache, should be much faster.
3. Run dig +trace www.cisco.com: watch the recursive walk happen step-by-step from root to TLD to authoritative.
4. On a Cisco router, configure ip name-server 1.1.1.1. Then run ping www.cisco.com and verify DNS resolution works.
5. Disable ip domain-lookup. Mistype a command. Confirm you no longer wait 30s for the prompt.
6. Bonus: change the TTL on a test domain you control. Watch propagation time difference.

Cheat strip

Frequently asked questions

Q: What’s the difference between recursive and iterative DNS? A: A recursive resolver does the whole lookup on the client’s behalf, asking the root, then TLD, then authoritative servers until it gets an answer. An iterative resolver only tells you where to look next (e.g., “ask the .com TLD server”). Client stubs always talk to recursive resolvers (8.8.8.8, 1.1.1.1, your ISP’s): the recursive resolver does the iterative walk.

Q: What’s a CNAME vs an A record? A: An A record maps a hostname directly to an IPv4 address (www.example.com → 93.184.216.34). A CNAME is an alias pointing at another hostname (www.example.com → example.com). CNAMEs let you point multiple hostnames at a single canonical record; changing the canonical A record updates every CNAME automatically. Common gotcha: you can’t CNAME the apex (example.com itself). Use an ALIAS or ANAME record if your DNS provider supports it.

Q: Why do I sometimes see stale DNS results? A: Caching: every DNS record has a TTL (time-to-live). Once a resolver caches a response, it keeps returning that answer until the TTL expires. Common TTLs: 300s (5 min) for fast-changing records, 86400s (24 hr) for stable ones. When you plan a DNS migration, lower TTLs a day ahead so the switchover propagates quickly. Client OSes also cache: Windows ipconfig /flushdns, macOS sudo dscacheutil -flushcache.

Q: What is DNS over HTTPS (DoH)? A: DNS queries wrapped in HTTPS instead of clear-text UDP 53. Prevents ISPs and network operators from seeing what domains a user visits (or from tampering with responses). Firefox, Chrome, and iOS/macOS all support it. Enterprise networks often try to block DoH because it bypasses DNS-based content filters. Expect a policy debate on whether to enable it in your org.

Q: What port does DNS use? A: UDP 53 for normal queries. TCP 53 for responses > 512 bytes and for zone transfers between authoritative servers. DoH uses TCP 443 (piggybacking on HTTPS). DoT (DNS over TLS) uses TCP 853. When you write a firewall rule allowing DNS, allow both UDP and TCP 53, otherwise DNSSEC and large TXT records fail.