This chapter covers a NEW objective in the CCNA v2 exam (200-301 v2.0, 2026 blueprint): diagnosing DNS record issues. DNS is the phonebook of the internet, and misconfigured records cause connectivity failures that are often misattributed to routing or switching. Cisco added this objective because modern networks depend on correct DNS resolution for everything from web browsing to email delivery and network management. Mastering A, AAAA, CNAME, MX, NS, and PTR records is essential for passing the exam and for real-world troubleshooting.
Jump to a section
Imagine a city where every building has a unique address (IP address) but people prefer to use names like "City Hall" or "Library" (domain names). The city directory (DNS) maintains several types of listings:
A record: Maps a building name to its street address (IPv4). If you look up "City Hall" and get "123 Main St", that's an A record.
AAAA record: Same as A, but for the new superblocks (IPv6) — e.g., "City Hall" maps to "1A:2B:3C::".
CNAME record: An alias. If "Mayor's Office" is really just "City Hall", a CNAME says "Mayor's Office → City Hall". The directory then looks up City Hall's address.
MX record: Tells the mail carrier which building handles mail for that city. For example, "City Hall" has an MX record pointing to "Mail.CityHall.gov" with a priority number — lower numbers are tried first.
NS record: Lists the directory offices themselves. If you ask for the address of "City Hall", the NS record tells you which directory branch (name server) has the authoritative listing.
PTR record: Reverse lookup — given an address like "123 Main St", find the building name. Used for verification (e.g., email servers check that the sender's IP resolves to a name matching the claimed domain).
When a record is wrong — e.g., a CNAME points to a nonexistent name, or an MX record has a typo — the directory lookup fails. Users get "server not found" errors, email bounces, or authentication failures. The network engineer must check each record type using commands like nslookup or dig to find the broken link.
What DNS Records Are and Why They Exist
DNS (Domain Name System) translates human-readable domain names (like www.example.com) into machine-readable IP addresses. The DNS database is distributed across a hierarchy of name servers, and each domain has resource records (RRs) of various types. The CCNA v2 exam tests your ability to diagnose issues with six record types: A, AAAA, CNAME, MX, NS, and PTR.
A Record (Address Record): Maps a domain name to an IPv4 address. This is the most fundamental record — without it, clients cannot reach a server by name.
AAAA Record (Quad-A Record): Maps a domain name to an IPv6 address. As IPv6 adoption grows, misconfigured AAAA records can cause dual-stack clients to fail over IPv6 unexpectedly.
CNAME Record (Canonical Name Record): Creates an alias from one domain name to another. The alias domain resolves to the same IP as the target. CNAME records cannot coexist with other record types for the same name (per RFC 1034).
MX Record (Mail Exchange Record): Specifies the mail server(s) responsible for receiving email for a domain. Each MX record has a priority value — lower numbers are preferred. Missing or wrong MX records cause email delivery failures.
NS Record (Name Server Record): Delegates a domain to a specific authoritative name server. NS records are critical for the DNS hierarchy — if they point to nonexistent or unreachable servers, the entire domain becomes unresolvable.
PTR Record (Pointer Record): Performs reverse DNS lookup — maps an IP address to a domain name. Used for verification (e.g., email servers check PTR records to reduce spam).
How DNS Resolution Works Step by Step
When a client wants to resolve www.example.com:
The client checks its local DNS cache. If not found, it sends a recursive query to its configured DNS resolver (e.g., 8.8.8.8).
The resolver queries the root name servers, which return the TLD name servers for .com.
The resolver queries the .com TLD servers, which return the NS records for example.com.
The resolver queries one of example.com's authoritative name servers, which returns the A record for www.example.com.
The resolver caches the result with a TTL (Time to Live) and returns it to the client.
At each step, a missing or incorrect record causes resolution failure. For example, if the NS record for example.com points to a dead server, step 4 fails.
Key Timers and Defaults
TTL (Time to Live): Specified in seconds in the SOA record (minimum TTL) or per record. Defaults vary, but common values are 300 (5 min) to 86400 (24 hours). Caching resolvers respect TTL; after expiry, they re-query.
Negative TTL: In the SOA record, tells resolvers how long to cache a negative response (NXDOMAIN). Default often 300-3600 seconds.
MX Priority: 0-65535. Lower values are preferred. If multiple MX records have the same priority, the resolver tries them in random order.
IOS CLI Verification Commands
Cisco IOS devices can perform DNS lookups and cache records, but they cannot host DNS zones. The key commands for diagnosis are:
R1# ping www.example.comIf DNS resolution fails, the ping will say "Translating "www.example.com"..." and then fail. To test DNS directly:
R1# nslookup www.example.comOn some IOS versions, you can also use:
R1# dig www.example.comBut these tools may be limited. More commonly, you use external tools like nslookup or dig from a PC. On a Windows PC:
C:\> nslookup www.example.comTo see all records:
C:\> nslookup -type=any example.comOr on Linux/Mac:
$ dig www.example.com ANYTo check MX records:
$ dig example.com MXTo check NS records:
$ dig example.com NSTo check PTR records (reverse lookup):
$ dig -x 192.0.2.1How DNS Interacts with Other Protocols
Email (SMTP): Mail servers use MX records to find the destination mail server. If MX records are missing or point to a non-existent host, email delivery fails with a "No MX record" bounce.
Web Browsing (HTTP/HTTPS): Browsers use A/AAAA records. If the record points to the wrong IP, users get a wrong website or connection timeout.
Certificate Validation: HTTPS certificates often include the domain name. If the DNS name doesn't match the certificate's Common Name (CN) or Subject Alternative Name (SAN), browsers show security warnings.
Reverse DNS (PTR): Many SMTP servers reject email from IPs that lack a PTR record matching the sending domain (anti-spam).
Common Record Misconfigurations
CNAME with other records: A CNAME record must be the only record for that name. If you have both a CNAME and an MX record for the same name, the DNS server might ignore one or cause unpredictable behavior.
Missing trailing dot: In zone files, fully qualified domain names (FQDNs) must end with a dot. Missing dot causes relative resolution errors.
Non-existent target: A CNAME or MX record points to a hostname that does not exist (no A/AAAA record). This causes resolution failure.
TTL too high: After a record change, high TTL causes long propagation delays. Clients and resolvers use cached old data until TTL expires.
NS records pointing to non-authoritative servers: If the NS record lists servers that do not actually host the zone, queries fail.
Identify the Symptom
The first step is to identify the failure symptom. Common symptoms include: web browser shows "server not found" or DNS_PROBE_FINISHED_NXDOMAIN; email bounces with "No MX record" or "Host not found"; ping fails with "Ping request could not find host"; nslookup returns "Non-existent domain". Determine which service is affected (web, email, etc.) to narrow down the record type. For example, web browsing failure suggests A/AAAA/CNAME issues; email failure suggests MX or PTR issues; entire domain unreachable suggests NS issues.
Verify DNS Resolution with nslookup/dig
Use nslookup or dig to manually query the DNS records. Start with the basic A record: `nslookup www.example.com`. If it fails, try querying the authoritative name server directly: `nslookup www.example.com ns1.example.com`. This bypasses caching resolvers. For email issues, query MX: `nslookup -type=MX example.com`. For reverse lookup issues, use `nslookup <IP>`. Check the response: if it returns an IP, the A record exists; if it returns "server failed" or "NXDOMAIN", the record is missing or the name server is unreachable.
Check for CNAME Conflicts
If a domain name is supposed to be an alias (e.g., www.example.com points to example.com), verify that there is a CNAME record. Use `nslookup -type=CNAME www.example.com`. If the response is an IP address instead of a canonical name, the record is an A record, not CNAME. Also check that the CNAME target has an A/AAAA record. Common mistake: CNAME pointing to a name that itself is a CNAME (CNAME chaining) — this violates RFC and may not resolve correctly. Use dig to see all records: `dig www.example.com ANY`.
Validate MX Records and Priority
For email issues, query the MX records: `nslookup -type=MX example.com`. The response should list one or more mail servers with priority numbers. Ensure that each mail server hostname (e.g., mail.example.com) has an A or AAAA record. Use `nslookup mail.example.com` to verify. Also check that the priority values are sensible — the lowest number should be the primary mail server. If MX records point to a hostname that does not exist (NXDOMAIN), email delivery fails. Also check that the mail server is reachable (ping/telnet to port 25).
Examine NS Records for Delegation
If the entire domain is unresolvable, check the NS records. Query the parent zone (e.g., .com TLD) for the domain's NS records: `nslookup -type=NS example.com`. The response should list authoritative name servers. Then check that each listed name server has an A record (glue record) and is reachable. Use `nslookup ns1.example.com` and try to query the zone directly: `nslookup example.com ns1.example.com`. If the NS records point to servers that don't exist or are unreachable, the domain is effectively dead.
Test PTR Records for Reverse Lookup
For services that require reverse DNS (e.g., email servers), test PTR records. Use `nslookup <IP>` or `dig -x <IP>`. The response should return a hostname. Verify that this hostname matches the forward DNS (A/AAAA) record — the IP should resolve to the same name. Common issue: PTR record missing or pointing to a generic name like "static-ip-xxx.provider.com" instead of the server's FQDN. This can cause email rejection. Also check that the forward DNS (A record) resolves back to the same IP (forward-confirmed reverse DNS).
Enterprise Scenario 1: Email Delivery Failure Due to Missing MX Record
A company, example.com, recently migrated its email to a new provider. After the migration, external email senders started receiving bounces: "550 5.1.2 Recipient unknown" or "No MX record for example.com". The IT team discovered that the MX record in the public DNS zone still pointed to the old mail server, which had been decommissioned. The fix: update the MX record to point to the new mail server's hostname (e.g., mail.example.com) with the correct priority. They also verified that the mail server hostname had an A record. This is a common scenario during cloud migrations — if you forget to update DNS, email breaks.
Enterprise Scenario 2: Website Unreachable Due to CNAME Misconfiguration
A web team created a CNAME record for "www.example.com" pointing to "example.com", but they also had an A record for "www.example.com" from a previous configuration. Because CNAME records cannot coexist with other record types, the DNS server ignored the CNAME and used the old A record, which pointed to a decommissioned IP. Users got a timeout. The fix: remove the old A record so the CNAME takes effect, and ensure the target (example.com) has a valid A record. This highlights the importance of understanding RFC 1034 restrictions.
Enterprise Scenario 3: Slow DNS Propagation After Server Migration
A hosting provider migrated example.org to a new IP address. They updated the A record, but the TTL was set to 86400 (24 hours). For a full day, many users still reached the old server. The fix: before the migration, lower the TTL to 300 (5 minutes) to allow quick propagation. After the migration, increase TTL back to a higher value. This is a best practice — always plan TTL changes ahead of infrastructure moves.
Performance and Scale Considerations
In large enterprises, DNS queries can be thousands per second. Misconfigured records cause cascading failures: if an NS record points to a server that is overloaded or down, all queries for that domain fail. Using multiple redundant name servers (NS records) and mail servers (MX records with different priorities) improves resilience. Regularly audit DNS records using tools like dig and nslookup to catch typos and missing records before they cause outages.
What CCNA 200-301 v2 Tests on This Topic
The exam objective 4.4 specifically requires you to "diagnose DNS record issues." This means you will be given a scenario (e.g., users can't access a website, email bounces, or a domain is unreachable) and you must identify which DNS record type is misconfigured and why. You will NOT be asked to configure DNS records on a Cisco device (routers/switches are not DNS servers). Instead, you will use show commands or the output of nslookup/dig to determine the problem.
New in CCNA v2
In CCNA v1.1, DNS was mentioned only briefly (e.g., setting DNS server on a router). The v2 blueprint adds explicit focus on diagnosing record types — A, AAAA, CNAME, MX, NS, PTR. This reflects real-world needs: network engineers often troubleshoot DNS misconfigurations that cause application failures. Candidates who studied v1.1 are missing this critical skill. The new 5-domain blueprint places this under "Network Services and Security" (20% of exam).
Common Wrong Answers and Why
"The A record is missing" when the real problem is a CNAME pointing to a non-existent host. Candidates often jump to the most common record type, but if the alias target doesn't exist, the A record for the alias doesn't matter.
"The MX record priority is too high" when the mail server hostname has no A record. Even with correct priority, if the mail server name doesn't resolve, email fails.
"The NS record is missing" when the glue record (A record for the name server) is missing. Candidates forget that name servers themselves need A records.
"PTR record is missing" when the forward DNS (A record) doesn't match. Both must match for reverse DNS to be useful.
Specific Values and Commands to Know
nslookup -type=MX example.com (Windows) or dig example.com MX (Linux/Mac)
nslookup -type=NS example.com
nslookup -type=CNAME www.example.com
nslookup -type=PTR <IP> (reverse lookup)
TTL values: 300 (5 min) vs 86400 (24 hours) — exam may ask which causes slower propagation.
MX priority: lower number = higher priority; default 10.
CNAME restriction: cannot coexist with other records for the same name.
Decision Rule for Scenario Questions
Determine the service: web (A/AAAA/CNAME), email (MX/PTR), domain resolution (NS).
Use the output of nslookup/dig to see which record type fails.
If the record returns an IP, check that the IP is reachable (ping).
If the record returns NXDOMAIN, the record is missing or the target doesn't exist.
If the record returns a name but no further resolution, check that the target has its own A/AAAA record.
A record maps hostname to IPv4; AAAA maps to IPv6.
CNAME creates an alias and must be the only record for that name.
MX records specify mail servers with priority; lower priority is tried first.
NS records delegate a domain to authoritative name servers.
PTR records perform reverse DNS lookup (IP to hostname).
Common diagnostic commands: nslookup, dig, ping.
[CCNA v2 NEW] Diagnosing DNS record issues is a new exam objective; focus on identifying which record type is misconfigured based on failure symptoms.
TTL affects propagation time; lower TTL speeds up changes.
CNAME chaining (CNAME pointing to CNAME) is not recommended and may fail.
These come up on the exam all the time. Here's how to tell them apart.
A Record
Maps hostname to IPv4 address
32-bit address
Most common for current internet
Example: 192.0.2.1
Used when client uses IPv4
AAAA Record
Maps hostname to IPv6 address
128-bit address
Growing in importance with IPv6 deployment
Example: 2001:db8::1
Used when client uses IPv6
CNAME Record
Creates an alias for a hostname
Must be only record for that name
Target must have A/AAAA record
Used for web redirection (e.g., www to root)
No priority; just points to canonical name
MX Record
Specifies mail server for domain
Can coexist with other records for same name (except CNAME)
Target must have A/AAAA record
Used for email delivery
Has priority value (lower is preferred)
Mistake
DNS only uses A records.
Correct
DNS uses multiple record types: A, AAAA, CNAME, MX, NS, PTR, etc. Each serves a different purpose.
Candidates often only think of A records because they are most familiar, but the exam tests other types.
Mistake
A CNAME record can have other records (like MX) for the same name.
Correct
Per RFC 1034, a CNAME record must be the only record type for that domain name. Coexisting records cause undefined behavior.
Real-world DNS software may allow it but with unpredictable results; the exam follows RFC.
Mistake
MX record priority works like a metric — higher values are better.
Correct
Lower priority values are preferred. If multiple MX records have the same priority, they are used in random order.
The word 'priority' is misleading; candidates often assume higher is better like OSPF metrics.
Mistake
PTR records are optional and not important for email delivery.
Correct
Many email servers reject mail from IPs without a PTR record that matches the sending domain. PTR is crucial for anti-spam.
Candidates may not realize that reverse DNS is used for verification, not just forward resolution.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An A record directly maps a hostname to an IPv4 address. A CNAME maps an alias hostname to another canonical hostname, which then must have its own A record. For example, www.example.com might be a CNAME pointing to example.com, and example.com has an A record with the IP. Use CNAME when you want multiple hostnames to resolve to the same IP without duplicating the A record. The exam tests that CNAME cannot coexist with other records for the same name.
Use the nslookup command: open Command Prompt and type `nslookup -type=MX example.com`. The output will list mail servers with their priority. For example: `example.com MX preference = 10, mail exchanger = mail.example.com`. If you get 'Non-existent domain', the MX record is missing.
A glue record is an A record for a name server that is part of the same domain. For example, if the NS record for example.com lists ns1.example.com, the resolver needs to know the IP of ns1.example.com to query it. But ns1.example.com is under example.com, creating a chicken-and-egg problem. The glue record (A record) for ns1.example.com is provided by the parent zone (.com TLD) to break the cycle. Without glue records, the domain may be unresolvable.
Many mail servers (especially those using SPF/DKIM/DMARC) perform a reverse DNS lookup on the connecting IP. If the PTR record is missing or points to a generic hostname (e.g., 203-0-113-5.static.provider.com) that does not match the sending domain's A record, the mail server may reject the email as spam. To fix, ensure the PTR record points to a hostname that matches the forward DNS (A record) and is under your control.
It means the DNS query returned an NXDOMAIN response, indicating that the domain name does not exist in the DNS hierarchy. This could be because the domain is not registered, the NS records are missing, or the specific record type (e.g., A, MX) does not exist for that name. If you get NXDOMAIN for a domain you know exists, check the NS records in the parent zone.
Yes, CNAME records can point to any hostname, even in a different domain (e.g., www.example.com CNAME to www.other.com). However, the target must have an A or AAAA record that resolves. This is common for content delivery networks (CDNs). The exam may test that CNAME can point outside the zone.
TTL (Time to Live) tells resolvers how long to cache a record. If you change a DNS record but the TTL is high (e.g., 86400 seconds = 24 hours), clients may still use the old cached data for up to a day. When troubleshooting, always check the TTL of the record you changed. Lowering TTL before a migration speeds up propagation. The exam may ask you to identify why changes are not taking effect immediately.
You've just covered Diagnosing DNS Record Issues — A, AAAA, CNAME, MX, NS, and PTR Records — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?