N10-009 Question 287
Single answerUsers in one office report that they can open websites by IP address, but they cannot reach any internal servers or internet sites by hostname. The network technician confirms that the users' PCs have valid IP addresses, can ping the default gateway, and can reach 8.8.8.8 successfully. To establish a theory of probable cause before making changes, which troubleshooting approach is the BEST next step?
- A
Use a top-to-bottom OSI approach and begin by checking application-layer name resolution settings, such as DNS server configuration and DNS responses
- B
Use a bottom-to-top OSI approach and start by replacing patch cables on affected PCs because most connectivity issues begin at Layer 1
- C
Use a divide-and-conquer approach by immediately rebooting the core switch to determine whether the issue is isolated to switching infrastructure
- D
Assume the ISP is blocking outbound web traffic and escalate the issue because successful pings do not rule out WAN failure
Show answer and explanation
Correct answer: A
Explanation
The best answer is to begin with DNS using a top-to-bottom OSI troubleshooting approach. In Network+ troubleshooting methodology, establishing a theory of probable cause requires using the symptoms already observed instead of making disruptive guesses. Here, the evidence shows that lower OSI layers are functioning: clients have valid IP configuration, can reach the local gateway, and can communicate with an external IP address. That makes DNS the most probable cause. Questioning the obvious means not stopping at the vague statement 'the internet is down' and instead recognizing the narrower pattern: hostname resolution is failing while IP connectivity is intact. Multiple approaches are valid in theory, but the best approach depends on the symptoms. CompTIA troubleshooting best practices emphasize identifying the problem, establishing a theory of probable cause, testing that theory, and using the most efficient and least disruptive method first. In practice, the technician would verify DNS server addresses with tools such as ipconfig /all, test resolution with nslookup or dig, and confirm whether internal and external DNS queries succeed.
- A. Correct.
Correct. The symptoms strongly suggest a name resolution problem rather than a general connectivity failure. The hosts have IP connectivity: they have valid addressing, can reach the default gateway, and can ping a public IP address. Because access by IP works but access by hostname fails, a top-to-bottom approach is appropriate here: start at the application layer and verify DNS settings, DNS server reachability, and whether DNS queries return valid records. This aligns with questioning the obvious and forming a probable cause based on the evidence already collected.
- B. Incorrect.
Incorrect. A bottom-to-top approach is valid in some cases, especially when there is no connectivity at all, but the evidence here already shows that Layer 1 through Layer 3 are functioning well enough for IP communication. Replacing cables would be a plausible first step only if there were signs of link failure, packet loss related to physical issues, or no connectivity. Choosing this option reflects the common mistake of ignoring gathered evidence and defaulting to physical-layer troubleshooting.
- C. Incorrect.
Incorrect. Divide and conquer is a legitimate troubleshooting method, but immediately rebooting the core switch is not an appropriate way to apply it in this scenario. There is no indication of a switching failure because clients can reach the gateway and an external IP. Rebooting production infrastructure without evidence is poor practice and can introduce a larger outage. A proper divide-and-conquer step would isolate whether DNS queries fail locally, at the DNS server, or upstream.
- D. Incorrect.
Incorrect. The ISP blocking outbound web traffic does not fit the reported symptoms. Users can reach a public IP, which indicates WAN connectivity is present. Also, the inability to reach internal servers by hostname points more directly to DNS or name resolution than to ISP filtering. This option reflects a common misconception: escalating externally before ruling out simpler and more probable internal causes.