In enterprise Windows environments, legacy protocols like Web Proxy Auto-Discovery (WPAD) and Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) represent well-known vector targets for man-in-the-middle (MitM) attacks and credential harvesting. To protect enterprise domain name resolution, Microsoft implements the Global Query Block List (GQBL). By default, Windows DNS servers and client resolvers refuse to resolve specific high-risk names unless explicitly allowed. Managing these parameters via PowerShell provides systems administrators with granular control over network name resolution security in Windows 11.
What is the DNS Global Query Block List?
The DNS Global Query Block List feature instructs the DNS resolution engine to block lookups for specific predetermined hostnames. Historically, attackers on an internal network could register a machine named wpad on an unprotected local subnet. Once registered, unconfigured client browsers would automatically query the rogue machine for proxy configuration scripts, allowing attackers to intercept web traffic.
By enforcing a global block list, the DNS resolver immediately treats queries for blocked hostnames as non-existent (returning NXDOMAIN), preventing unauthorised proxy injection or tunnelling manipulation.
Viewing Current DNS Client Query Configuration in PowerShell
To inspect DNS client resolver settings and query parameters in Windows 11:
- Right-click the Start button on Windows 11 (or press
Win + X). - Select Terminal (Admin) or PowerShell (Admin).
- Execute the following cmdlet to inspect general DNS client global settings:
Get-DnsClientGlobalSetting - To review DNS client policies applied across network interfaces:
Get-DnsClientPolicy
Managing DNS Server Global Query Block Lists via PowerShell
When Windows 11 devices interact with Windows Server DNS roles or local testing DNS servers running the DnsServer PowerShell module, administrators can directly query and update the block list.
Checking the Block List Status and Blocked Names
To verify whether the Global Query Block List is currently active and inspect the blocked hostname list:
Get-DnsServerGlobalQueryBlockListBy default, the list contains two hostnames: wpad and isatap.
Adding Custom Hostnames to the Block List
If security requirements dictate that additional sensitive internal names (such as legacy WPAD variants or internal staging names) should never be resolved by network clients, they can be appended to the list:
$currentList = (Get-DnsServerGlobalQueryBlockList).List
$currentList += "wpad2"
$currentList += "teredo-relay"
Set-DnsServerGlobalQueryBlockList -List $currentListRemoving Hostnames from the Block List
If an enterprise operates a legitimate, authenticated WPAD server and explicitly requires internal clients to resolve the hostname via authoritative DNS:
Set-DnsServerGlobalQueryBlockList -List "isatap"Executing this command retains isatap in the block list while removing wpad, allowing legitimate resolution.
Enforcing Client-Side DNS Name Resolution Blocking in Windows 11
On standalone Windows 11 client machines where server-side DNS cmdlets are not locally present, client-side name interception can be enforced using the Windows DNS Client NRPT (Name Resolution Policy Table) or Windows Defender Firewall rules via PowerShell.
Configuring an NRPT Rule to Intercept Specific Hostnames
Administrators can configure the client resolver to block lookups for vulnerable names using Group Policy cmdlets or PowerShell registry manipulation:
$registryPath = "HKLM:\System\CurrentControlSet\Services\Dnscache\Parameters"
Set-ItemProperty -Path $registryPath -Name "EnableGlobalQueryBlockList" -Value 1 -Type DWordFlushing the Windows 11 DNS Resolver Cache
After modifying DNS query policies or block lists, flush the local client resolver cache to purge any cached responses:
Clear-DnsClientCacheVerify that querying the blocked record returns an immediate failure without network traversal:
Resolve-DnsName -Name "wpad" -ErrorAction SilentlyContinueSecurity Considerations and Best Practices
Maintaining Global Query Block Lists protects local subnets against dynamic DNS registration exploits. When deploying proxy infrastructure, enterprise environments should prefer Group Policy or Microsoft Intune configuration profiles rather than relying on legacy automatic WPAD broadcasts.