When working with local development environments or testing public endpoints, we often modify the Windows hosts file (C:\Windows\System32\drivers\etc\hosts) to map domains to specific IP addresses. However, many developers encounter a frustrating scenario where nslookup completely ignores these entries.

# Example hosts file entry that doesn't work with nslookup
210.210.210.10 my.domain.com

Unlike most applications that consult the hosts file first, nslookup is specifically designed to query DNS servers directly. This is actually by design - it's a diagnostic tool meant to test DNS resolution independently of the local hosts file.

For validation that your hosts file entries are working, try these alternatives:

# Using ping (respects hosts file)
ping my.domain.com

# Using PowerShell Test-Connection
Test-Connection my.domain.com

# Using curl to test web services
curl http://my.domain.com

While you can't make standard nslookup use the hosts file, you can create a PowerShell function that mimics this behavior:

function Get-HostEntry {
    param(
        [string]$Hostname
    )
    
    $hostsPath = "$env:windir\System32\drivers\etc\hosts"
    $hostsEntries = Get-Content $hostsPath | Where-Object { $_ -notmatch '^#' -and $_ -match "\s+$Hostname" }
    
    if ($hostsEntries) {
        $ip = ($hostsEntries -split '\s+')[0]
        return [PSCustomObject]@{
            Hostname = $Hostname
            IP = $ip
            Source = 'Hosts File'
        }
    }
    else {
        try {
            $dnsEntry = [System.Net.Dns]::GetHostEntry($Hostname)
            return [PSCustomObject]@{
                Hostname = $Hostname
                IP = $dnsEntry.AddressList[0].IPAddressToString
                Source = 'DNS'
            }
        }
        catch {
            Write-Warning "Unable to resolve $Hostname"
        }
    }
}

# Usage example
Get-HostEntry "my.domain.com"

If you need to verify DNS behavior while accounting for hosts file entries, combine both approaches:

# First check hosts file
Get-Content "$env:windir\System32\drivers\etc\hosts" | Select-String "my.domain.com"

# Then check DNS
nslookup my.domain.com

Remember that most applications (web browsers, APIs, etc.) will respect the hosts file entries. The nslookup behavior is specific to that tool and doesn't indicate a system-wide issue. For development purposes, focus on testing with the actual applications you're using rather than relying solely on nslookup.

When working with domain name resolution on Windows, many developers encounter situations where nslookup bypasses the hosts file and queries DNS servers directly. Here's a deep dive into why this happens and how to enforce hosts file usage.

# Example hosts file entry being ignored
210.210.210.10 my.domain.com

The nslookup tool is designed specifically for DNS troubleshooting and intentionally bypasses the local hosts file to query DNS servers directly. This is actually by design - it helps administrators test DNS resolution independently of local overrides.

# What you see when it ignores hosts file
nslookup my.domain.com
Server:  dns.company.local
Address:  10.10.10.10

Non-authoritative answer:
Name:    my.domain.com
Address:  10.10.10.10

If you need to test hosts file entries, consider these alternatives:

# Using ping (respects hosts file)
ping my.domain.com

# Using PowerShell Test-Connection
Test-Connection my.domain.com

# Using curl with --resolve option
curl --resolve "my.domain.com:80:210.210.210.10" http://my.domain.com

While not recommended for production use, you can temporarily force local resolution by:

# Create a local DNS server (like dnsmasq) pointing to 127.0.0.1
# Then configure nslookup to use it:
nslookup my.domain.com 127.0.0.1

• Use ping or browser access for basic hosts file validation
• Clear DNS cache after hosts file modifications: ipconfig /flushdns
• For development, consider using etc-hosts manager tools
• In scripts, use System.Net.Dns.GetHostEntry() in PowerShell/C# which respects hosts file

# PowerShell example that respects hosts file
[System.Net.Dns]::GetHostAddresses("my.domain.com")