Troubleshooting DNS Spoofing on Intranet Site
Several employees complain that the company intranet site is no longer accepting their login information. You attempt to connect by using the URL and notice some misspellings on the site. When you connect by using the IP address, the site functions normally. What should you do?
Community Insight
The test focuses on distinguishing between application-level failures and network resolution issues; the common trap is assuming the web server itself is compromised when the symptom points to incorrect name resolution.
This question addresses a scenario where an intranet site displays misspellings and rejects logins via URL but works correctly via IP address, indicating a DNS resolution issue likely caused by spoofing or poisoning. It establishes that verifying the local DNS server's accuracy is the critical first step to resolve the discrepancy.
Candidates often select restoring the authentication database (A) because login failures are mentioned, failing to realize that the root cause is the URL resolving to a potentially malicious or incorrect IP due to DNS issues.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct action is to verify the accuracy of the entry for the site in the local DNS server (B). When a website functions normally via its direct IP address but exhibits errors like misspellings or failed authentications via its URL, it indicates that the domain name is resolving to an unexpected or incorrect IP address. This behavior is characteristic of DNS spoofing or poisoning, where attackers manipulate DNS records to redirect users. By checking the local DNS cache and configuration, you can confirm if the record has been altered and restore it to the legitimate IP.Why the Other Options Are Wrong
Restoring the authentication database (A) is unnecessary because the site works via IP, proving the backend services and databases are functional. Taking the portal offline (C) is a drastic measure that disrupts business continuity before confirming an active attack or severity; while containment might be needed later, diagnosis comes first. Updating web server software (D) addresses version vulnerabilities but does not fix the immediate issue of the URL pointing to the wrong destination.Community Comment Notes
Community feedback strongly supports Option B, with commenters noting that since the site works via IP, the underlying infrastructure is healthy. One user highlighted that the misspellings and login rejections indicate a DNS spoofing attack where users are being redirected. Another comment emphasized that this is a classic symptom of DNS poisoning, requiring immediate verification of DNS entries rather than application-side fixes.Exam Strategy
Always correlate symptoms with the method of access; if IP works but URL fails, suspect DNS or host file issues before blaming the application server. Look for clues like 'misspellings' which suggest content from a different source, reinforcing the DNS redirection hypothesis.
Frequently Asked Questions
Why isn't restoring the auth database the right answer?
Because the site works via IP, the database is accessible and functional. The failure is isolated to the URL resolution process.
How do I distinguish DNS spoofing from a server crash?
If the server responds correctly via direct IP but serves incorrect content or errors via URL, the server is up but the name resolution is compromised.