N10-009 Question 325
Select 2A systems administrator is troubleshooting why users on a Linux server cannot reach an internal web application by name. Users report that http://intranet.corp.local fails, but they can access the site directly by entering the server's IP address in a browser. The administrator wants to verify whether the issue is DNS-related from the Linux server itself and also see what DNS traffic is being exchanged in real time. Which TWO tools should the administrator use first?
- A
dig
- B
tcpdump
- C
netstat
- D
arp
- E
traceroute
Show answer and explanation
Correct answers: A, B
Explanation
This scenario points strongly to a name resolution problem because the web application is reachable by IP address but not by hostname. Best practice is to first test the suspected service directly, then inspect supporting traffic if needed. On Linux, dig is one of the standard tools for querying DNS and confirming whether a hostname resolves correctly. tcpdump is a packet capture tool commonly used to verify whether DNS requests and responses are actually traversing the network. Together, they allow both application-level and packet-level validation.
By contrast, netstat is more useful for checking local sockets and connection states, arp is for local Layer 2 address resolution, and traceroute is for path discovery. Those tools can be useful in other troubleshooting workflows, but they are not the best initial choices for a hostname-only failure where IP connectivity is already confirmed.
These uses align with standard vendor and platform documentation: dig is documented as a DNS lookup utility in BIND tools, and tcpdump is a standard packet analyzer for capturing traffic on Unix-like systems. Network troubleshooting best practices also emphasize isolating whether the failure is DNS, transport, or routing related before expanding the scope of investigation.
- A. Correct.
Correct. The dig command is designed to query DNS servers and display detailed DNS response information, such as record type, answer section, authority section, and which DNS server replied. In this scenario, because the application works by IP address but not by hostname, testing name resolution directly is the most appropriate first step. Using dig intranet.corp.local helps confirm whether the Linux server can resolve the host and whether the returned record is correct.
- B. Correct.
Correct. tcpdump is appropriate for capturing and viewing DNS packets in real time on a Linux system. The administrator can use it to confirm whether DNS queries are leaving the server, whether responses are returning, and whether there are timeouts, malformed responses, or traffic going to the wrong DNS server. This complements dig by showing packet-level behavior rather than just command output.
- C. Incorrect.
Incorrect. netstat displays network connections, listening ports, routing tables, and interface statistics, depending on switches and platform. While it can help identify established sessions or whether a local service is listening, it is not the best first tool to validate DNS resolution of a hostname or inspect DNS query/response traffic in this scenario.
- D. Incorrect.
Incorrect. arp displays or manipulates the local ARP cache, which maps IPv4 addresses to MAC addresses on the local network segment. Since the users can reach the site by IP address, Layer 2 neighbor resolution is not the primary suspected issue. ARP does not test DNS name resolution.
- E. Incorrect.
Incorrect. traceroute shows the Layer 3 path packets take toward a destination and can help identify routing issues or hops causing latency. However, the problem description already indicates the application is reachable by IP address, which makes routing less likely to be the immediate issue. traceroute also does not directly verify DNS responses or show DNS packet contents.