A network security analyst is troubleshooting an issue where a Linux workstation fails to resolve internal hostnames after a recent network migration, though IP-based routing functions normally. What is the correct logical sequence of diagnostic steps to systematically isolate and resolve this name resolution failure?
- 1Examine `/etc/resolv.conf` to verify the configured nameserver IP addresses and search domains.
- 2Run `dig @<configured_dns_ip> internal.example.com` to test DNS transport and resolver responsiveness.
- 3Check `/etc/hosts` for conflicting static IP-to-hostname mappings that take precedence over DNS.
- 4Flush the local resolver cache (`resolvectl flush-caches`) to clear negative or stale DNS entries.
Answer
The correct logical sequence starts with inspecting `/etc/resolv.conf`, followed by directly querying the configured DNS server using `dig`, checking `/etc/hosts` for conflicting static entries, and finally flushing the local resolver cache.
Methodological troubleshooting progresses from checking local system configuration (`/etc/resolv.conf`), to testing DNS server transport responsiveness via direct utility queries (`dig`), checking local resolution overrides (`/etc/hosts`), and lastly purging stale system cache (`resolvectl flush-caches`).
Step-by-Step Solution
Key Concept
OS Name Resolution Troubleshooting Sequence