In troubleshooting, you can reach a host by its IP address but not by its name. Which factor is most likely the cause of the name-based communication failure?

Difficulty: Easy

Correct Answer: Static name sources such as an LMHOSTS file or a DNS database entry

Explanation:


Introduction / Context:
When connectivity by IP works but name lookups fail, the network path is usually fine. The problem instead lies with name resolution—how a textual name maps to an IP address. Understanding typical name sources helps quickly narrow the root cause in Microsoft, Linux, and mixed environments.


Given Data / Assumptions:

  • Pinging or connecting via raw IP succeeds.
  • Attempting to reach the same host by its name fails or resolves incorrectly.
  • Name resolution may rely on DNS, WINS/NetBIOS, mDNS, or local static files like hosts/LMHOSTS.


Concept / Approach:
Name resolution is a separate step preceding connection. If the IP path is good, then DNS records (A/AAAA), NetBIOS/WINS entries, or static mappings may be missing, stale, or misconfigured. For legacy Windows name lookups, LMHOSTS/WINS can override DNS; on Unix-like systems, /etc/hosts or nsswitch.conf order can affect outcomes. Thus, incorrect or missing entries in these static or server-side databases commonly cause “name works for some, not others” scenarios.


Step-by-Step Solution:

Verify that direct IP connectivity succeeds → confirms routing and layer-3 path. Attempt name resolution (nslookup/dig/getent/nbtstat) → identify failures or wrong answers. Inspect DNS zone entries, WINS registrations, and local hosts/LMHOSTS files for stale or conflicting mappings. Correct the faulty record or flush caches to restore name-based connectivity.


Verification / Alternative check:
Clearing resolver caches (ipconfig /flushdns, systemd-resolved, or browser cache) often fixes transient issues. Packet captures show DNS queries leaving the client and the responses (NXDOMAIN, SERVFAIL, or wrong IP), pinpointing the database error rather than a routing problem.


Why Other Options Are Wrong:

  • The IP address itself: connectivity by IP is already proven to work.
  • Subnet mask: would affect IP reachability, not just name resolution.
  • Default gateway: misconfiguration would break IP paths, not only names.
  • MTU size: impacts fragmentation/throughput, not basic name mapping.


Common Pitfalls:
Assuming firewall rules selectively block DNS but not application traffic; overlooking split-horizon DNS where internal/external names differ; forgetting that VPN DNS settings can override local resolvers.


Final Answer:
Static name sources such as an LMHOSTS file or a DNS database entry

More Questions from Networking

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion