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:
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:
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:
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
Discussion & Comments