Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
CCNA Network Services and Security Practice Question
Drag and drop the following steps into the correct order to sequence the DNS resolution process from a client query to receiving an A-record response, followed by the diagnostic workflow using nslookup and dig to identify a missing or incorrect A-record.
⚠ Common exam trap
Do not confuse the client's initial query destination (configured DNS server, not root) and remember the troubleshooting order: nslookup before dig +trace. Also, avoid inserting extra steps like explicit cache returns.
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
✓
Client sends DNS query to configured DNS server → DNS server checks cache and forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses nslookup to verify → Client uses dig +trace for detailed path analysis
The standard DNS resolution sequence ends with the client receiving the A-record. Troubleshooting uses nslookup first for basic checks, then dig +trace for detailed path analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Client sends DNS query to configured DNS server → DNS server checks cache and forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses nslookup to verify → Client uses dig +trace for detailed path analysis
Why this is correct
This sequence correctly follows the standard DNS resolution process: the client query goes to the configured DNS server, which then iteratively queries root, TLD, and authoritative servers to obtain the A-record. After resolution, nslookup is used for basic verification, and dig +trace provides detailed path analysis for troubleshooting.
- ✗
Client sends DNS query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses dig +trace → Client uses nslookup to verify
Why it's wrong here
This sequence is technically invalid because a DNS client never sends queries directly to a root server. An end host is configured with a recursive resolver (its DNS server), which uses root hints to perform iterative queries on behalf of the client; direct root queries would be nonstandard and blocked by network policy. Additionally, the troubleshooting tool order is reversed: nslookup provides a quick basic verification (confirming resolution and the configured server), while dig +trace is the detailed follow-up used to expose the full resolution path only after a basic failure is suspected.
- ✗
Client sends DNS query to configured DNS server → DNS server checks cache and forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses dig +trace → Client uses nslookup to verify
Why it's wrong here
Although the DNS resolution sequence itself is correct (configured recursive server, root, TLD, authoritative, A-record returned), the troubleshooting step order is backwards. nslookup should always be run first because it quickly confirms whether the configured DNS server can resolve the name and to what address, using the client's normal lookup mechanism. dig +trace is a more advanced diagnostic that sends iterative queries and prints each step, so it is better suited for tracing where resolution fails after nslookup has already established the basic answer.
- ✗
Client sends DNS query to configured DNS server → DNS server checks cache and returns A-record from cache → If not cached, server forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses nslookup → Client uses dig +trace
Why it's wrong here
This is incorrect because it includes an unnecessary step about returning from cache before the full iterative query. The standard process does not include a separate cache check step that returns the record before forwarding; the cache check is part of the DNS server's logic but not a separate step in the resolution sequence.
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.
✓Client sends DNS query to configured DNS server → DNS server checks cache and forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses nslookup to verify → Client uses dig +trace for detailed path analysisCorrect answer▾
Why this is correct
This sequence correctly follows the standard DNS resolution process: the client query goes to the configured DNS server, which then iteratively queries root, TLD, and authoritative servers to obtain the A-record. After resolution, nslookup is used for basic verification, and dig +trace provides detailed path analysis for troubleshooting.
✗Client sends DNS query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses dig +trace → Client uses nslookup to verifyWrong answer — click to see why▾
Why this is wrong here
The client's initial query is to its configured DNS server, not directly to a root server. Additionally, nslookup is typically used before dig for basic verification.
Why candidates choose this
Candidates may think the client directly queries root servers, or they may confuse the order of troubleshooting tools.
✗Client sends DNS query to configured DNS server → DNS server checks cache and forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses dig +trace → Client uses nslookup to verifyWrong answer — click to see why▾
Why this is wrong here
The standard troubleshooting workflow starts with nslookup (basic) and then dig +trace (detailed). Reversing them is not the recommended order.
Why candidates choose this
Candidates might think dig +trace is more powerful and should be used first, but nslookup is simpler and should be the initial diagnostic step.
✗Client sends DNS query to configured DNS server → DNS server checks cache and returns A-record from cache → If not cached, server forwards query to root server → Root server directs to TLD server → TLD server directs to authoritative server → Authoritative server returns A-record to client → Client uses nslookup → Client uses dig +traceWrong answer — click to see why▾
Why this is wrong here
The DNS server's cache check is implicit and not a separate step in the resolution flow. The sequence should show the query being forwarded to root servers if not cached, without an intermediate return step.
Why candidates choose this
Candidates may overcomplicate the process by explicitly including cache behavior, but the question expects the standard iterative resolution steps without extra detail.
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
Fully Qualified Domain Name
A Fully Qualified Domain Name is the complete and unambiguous website or server name that includes the host, domain, and top-level domain, leaving no room for guesswork.
Key term
Name Server
A name server is a specialized server that translates human-readable domain names into machine-readable IP addresses so that computers can find each other on a network.
About these practice questions
This 200-301 question is part of Courseiva's 1,389-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.