CCNA Network Services and Security Practice Question
Network Topology
You are connected to R1, a multilayer switch acting as a DNS client and DNS server for the local network. The network uses 192.168.1.0/24 for internal hosts. Users report that hostnames like 'server1.example.com' fail to resolve. Diagnose and fix the DNS resolution issue using nslookup and dig. Ensure that R1 can resolve both forward and reverse DNS queries correctly.
⚠ Common exam trap
Students often forget that reverse DNS requires a PTR record in addition to the A record. Also, they may not verify that the DNS forwarder is reachable; simply adding records without removing an unreachable forwarder will not fix forward lookups. Always check both forward and reverse resolution requirements.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure R1 as a local DNS server with an A record for server1.example.com (192.168.1.10) and a PTR record for 192.168.1.10, then remove the unreachable forwarder 192.0.2.53 and ensure ip domain lookup uses the local server.
The issue is twofold: first, the DNS forwarder (192.0.2.53) is unreachable, causing forward lookups to fail with NXDOMAIN; second, there is no PTR record for the reverse lookup zone. The forward lookup failure is because R1 is configured to use an unreachable external DNS server. The reverse lookup failure is because no PTR record exists for the host IP. To fix, either configure a reachable DNS forwarder or enable local DNS server with appropriate records. Here, we configure R1 as a local DNS server with an A record for 'server1.example.com' pointing to 192.168.1.10 and a PTR record for the reverse lookup. Then we remove the unreachable forwarder and ensure ip domain lookup uses local server.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure R1 as a local DNS server with an A record for server1.example.com (192.168.1.10) and a PTR record for 192.168.1.10, then remove the unreachable forwarder 192.0.2.53 and ensure ip domain lookup uses the local server.
Why this is correct
This resolves both issues: the forward lookup fails because the forwarder is unreachable, so using a local server with an A record fixes forward resolution; the reverse lookup fails due to missing PTR record, so adding one fixes reverse resolution. Removing the unreachable forwarder ensures queries go to the local server.
- ✗
Configure R1 as a DNS server with only an A record for server1.example.com (192.168.1.10) and keep the forwarder 192.0.2.53 for other queries.
Why it's wrong here
Keeping forwarder 192.0.2.53 makes the router still attempt to forward any query it cannot answer locally; because that forwarder is unreachable, both the A-record lookup for server1.example.com (if served locally) and, more importantly, the reverse lookup for 192.168.1.10 (which has no PTR entry) will time out and fail. While adding the A record would handle forward resolution, the router's DNS behavior for the reverse query is to forward it to the sole configured forwarder, which is dead. Without removing the unreachable forwarder and without a PTR record, reverse lookups remain broken.
- ✗
Remove the forwarder 192.0.2.53 and configure R1 as a DNS server with only a PTR record for 192.168.1.10.
Why it's wrong here
Removing the unreachable forwarder is a necessary fix, but configuring only a PTR record addresses only reverse resolution. The router still has no A record for server1.example.com, so any forward lookup for that name will fall through to iterative DNS queries using root hints, which cannot resolve an internal private-domain name. Even with a working DNS server on R1, the absence of an A record for server1.example.com means the `ping server1.example.com` command cannot resolve the name, so the forward issue persists.
- ✗
Change the DNS forwarder to a reachable server like 8.8.8.8 and add a PTR record for 192.168.1.10 on R1.
Why it's wrong here
This is incorrect because while changing the forwarder to a reachable server fixes forward lookups, the reverse lookup still requires a PTR record on the local server. However, the question implies R1 should act as a local DNS server, not rely on external forwarders for internal hostnames.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Configure R1 as a local DNS server with an A record for server1.example.com (192.168.1.10) and a PTR record for 192.168.1.10, then remove the unreachable forwarder 192.0.2.53 and ensure ip domain lookup uses the local server.Correct answer▾
Why this is correct
This resolves both issues: the forward lookup fails because the forwarder is unreachable, so using a local server with an A record fixes forward resolution; the reverse lookup fails due to missing PTR record, so adding one fixes reverse resolution. Removing the unreachable forwarder ensures queries go to the local server.
✗Configure R1 as a DNS server with only an A record for server1.example.com (192.168.1.10) and keep the forwarder 192.0.2.53 for other queries.Wrong answer — click to see why▾
Why this is wrong here
The forwarder is unreachable, so keeping it will cause forward lookups to fail. Also, reverse lookup requires a PTR record, which is missing.
Why candidates choose this
Candidates may think that adding an A record alone is sufficient and that the forwarder can be kept for other queries, not realizing the forwarder is unreachable.
✗Remove the forwarder 192.0.2.53 and configure R1 as a DNS server with only a PTR record for 192.168.1.10.Wrong answer — click to see why▾
Why this is wrong here
Forward lookups require an A record mapping the hostname to an IP address; without it, forward queries return NXDOMAIN.
Why candidates choose this
Candidates may focus only on the reverse lookup issue mentioned in the problem and forget that forward lookups also fail due to the unreachable forwarder.
✗Change the DNS forwarder to a reachable server like 8.8.8.8 and add a PTR record for 192.168.1.10 on R1.Wrong answer — click to see why▾
Why this is wrong here
The scenario expects R1 to be a local DNS server for internal hosts; using an external forwarder for internal hostnames is not best practice and may not resolve internal names if the forwarder doesn't have the records.
Why candidates choose this
Candidates may think that using a public DNS server like 8.8.8.8 is a quick fix for forward lookups, but they overlook the requirement for local resolution and reverse lookup.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Quick reference
Common DNS Record Types
| Record | Purpose | Example |
|---|---|---|
| A | IPv4 address mapping | example.com → 93.184.216.34 |
| AAAA | IPv6 address mapping | example.com → 2606:2800::1 |
| CNAME | Alias to another hostname | www → example.com |
| MX | Mail server for domain | example.com → mail.example.com (priority 10) |
| TXT | Text data (SPF, DKIM, verification) | v=spf1 include:_spf.example.com ~all |
| NS | Authoritative name servers | example.com NS ns1.example.com |
| PTR | Reverse DNS (IP → hostname) | 34.216.184.93.in-addr.arpa → example.com |
| SOA | Zone authority record | Primary NS, admin email, serial, TTL defaults |
Go deeper
Related to this question
Learn chapter
RA Guard — IPv6 First-Hop Security
Key term
A record
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Key term
DNS
DNS is the system that translates human-friendly domain names like example.com into machine-readable IP addresses so computers can find each other on a network.
About these practice questions
Courseiva writes every 200-301 question from scratch — 1,389 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.