N10-009 Question 294
Single answerImplement the solution or escalate as necessaryA network technician is troubleshooting a small branch office that cannot reach a newly deployed cloud-based inventory application. Users can browse other websites normally, and a ping to the application server's public IP address succeeds from a workstation. However, when users enter the application's URL, the browser returns a name resolution error. The technician verifies the issue affects all users at the site, while users at other offices can access the application without problems. The branch office uses a local DNS server that forwards unresolved requests to the ISP. Which of the following is the BEST action for the technician to implement next, based on the evidence gathered?
- A
Create or correct the DNS record on the branch DNS server or its forwarder path so the application's FQDN resolves properly
- B
Replace the branch office default gateway because successful pings to the public IP indicate a routing loop
- C
Disable HTTPS inspection on the firewall because browser errors to a URL usually indicate a certificate mismatch
- D
Escalate immediately to the cloud application vendor because successful IP connectivity proves DNS is working correctly
Show answer and explanation
Correct answer: A
Explanation
This question tests the ability to implement the solution after isolating the fault domain. The key evidence is that users can access other internet resources and can ping the application's public IP, which confirms general WAN connectivity and basic Layer 3 reachability. The failure occurs only when using the URL, pointing to DNS resolution as the likely root cause. In a Network+ context, the best action is to correct the local resolver path, such as a missing or stale record, an incorrect forwarder, or an issue with how the branch DNS server resolves external zones. This aligns with standard troubleshooting methodology: identify the problem, establish a theory, test the theory, implement the solution, and escalate only if the issue is outside the technician's control. Best-practice references include common enterprise DNS troubleshooting guidance from Microsoft DNS documentation and BIND administration practices, both of which emphasize verifying record accuracy, recursion, and forwarding behavior when hostname resolution fails but IP connectivity succeeds.
- A. Correct.
Correct. The scenario isolates the problem to name resolution, not general IP connectivity. Users can reach other websites, and they can ping the application's public IP, which shows routing and basic internet access are functioning. A browser error specifically tied to the URL, combined with success by IP address, strongly indicates a DNS issue. The best next step is to implement the fix by correcting the local DNS record, conditional forwarder, stub zone, or upstream forwarding configuration so the FQDN resolves.
- B. Incorrect.
Incorrect. If clients can reach other websites and ping the application's public IP, the default gateway is functioning well enough to route traffic off-site. A routing loop would typically cause broader connectivity failures, latency, or packet loss rather than a consistent name resolution error only for one application URL.
- C. Incorrect.
Incorrect. HTTPS inspection problems typically appear after successful DNS resolution and TCP/TLS negotiation, often as certificate warnings, blocked sessions, or browser trust errors. In this case, the browser reports a name resolution error, which occurs before any TLS inspection or certificate validation would matter.
- D. Incorrect.
Incorrect. Escalation is premature. The evidence does not show an application-side outage; in fact, other offices can access the service. Also, successful IP connectivity does not prove DNS is working correctly for the application's hostname. Since the technician has identified a likely internal DNS problem, best practice is to implement the local fix before escalating.