CompTIA Linux+ (XK0-006)TroubleshootingHard
A client reports that internal applications cannot resolve www.example.com. The technician runs: `dig @8.8.8.8 www.example.com` — returns a valid answer with status: NOERROR `dig www.example.com` (using the system's default resolver) — returns status: SERVFAIL What does this comparison indicate?
- AThe www.example.com domain itself is misconfigured and does not exist
- BThe client's network interface has no default gateway configured
- CThe problem lies with the client's configured local/internal DNS server, not the external domain
- DThe application server is down and not responding to HTTP requests
Show answer & explanationAnswer & explanation
Correct answer: C. The problem lies with the client's configured local/internal DNS server, not the external domain
Querying an external public resolver (8.8.8.8) directly succeeds, proving the domain resolves correctly on the internet. Since the client's default resolver (as configured in /etc/resolv.conf) returns SERVFAIL for the same query, the fault is isolated to the client's configured DNS server, not the domain or the destination server.
Why the other options are wrong
- A. The domain resolves fine via the external resolver, ruling out a domain configuration problem.
- B. A missing default gateway would cause connectivity issues, not a DNS-specific SERVFAIL from one resolver only.
- D. This test only checks DNS resolution, not HTTP/application availability.
dig for DNS Isolation
Using dig @<server> to directly query different DNS servers helps isolate whether a resolution failure is due to the client's configured resolver or the domain/authoritative server itself.
- dig @8.8.8.8 <name> bypasses local resolv.conf and queries directly
- SERVFAIL from one server but NOERROR from another isolates the faulty server
- Check /etc/resolv.conf to see which DNS server the client normally uses
Memory trick: Two dig results, two suspects — compare them to find the guilty resolver