The Problem: Connectivity Exists, Resolution Fails
 |
| Image generated with Gemini AI |
It is a recurring nightmare: the server successfully replies to ping 8.8.8.8, but attempting to reach an internal or external domain returns ERR_NAME_NOT_RESOLVED in the browser. The standard ipconfig /flushdns command had zero effect. In these advanced scenarios, simply restarting the network adapter is useless; you need to surgically inspect the resolution chain.
The Solution: Sysadmin Tools (dig and nslookup)
To diagnose exactly where the DNS chain breaks, we must bypass the operating system's cache and query the name servers directly.
1. Inspecting Resolution with `dig` or `nslookup`
On Linux (or WSL on Windows), use dig to trace the request path. Specify your corporate DNS server to see if it responds correctly to internal records (e.g., your intranet at intranet.local):
# Specifically query the corporate Domain Controller (10.0.20.5)
dig @10.0.20.5 intranet.localIf the server returns a SERVFAIL error, the issue lies within the DNS server's forwarders. If it returns NXDOMAIN, the record simply does not exist in the DNS zone.
2. The DNS over HTTPS (DoH) Browser Conflict
An increasingly common issue in corporate networks is caused by DNS over HTTPS (DoH). Modern browsers (Chrome, Edge, Firefox) bypass the Windows network adapter's DNS settings and encrypt requests, sending them directly to Cloudflare or Google. The result? The user can browse the public internet but cannot access internal corporate resources because the public DNS knows nothing about your private zone.
To fix this, disable "Secure DNS" within the browser's privacy settings, or enforce the block company-wide via Group Policy Objects (GPO).
3. Verifying Hosts and Resolv.conf
On Linux machines, ensure the resolution process is actually pointing to the correct server. Inspect the configuration file:
cat /etc/resolv.confIf the network is managed by systemd-resolved, check the global resolution status by executing:
resolvectl status
Commenti
Posta un commento