In recent times we’ve been regularly working with a number of wireless vendors completing both installations and maintenance in environments. This has led to us seeing more Cloud vendor metrics based around environment health and with this, we have noted some reporting quirks by multiple vendors. Vendors will provide health reports on associations, RF, DHCP, latency and in particular DNS.
In one of our heavily BYO Windows client environments with approximately 800-1200 users we’ve seen a very poor DNS score. This score has been as low as 80% however onsite investigation has shown DNS resolution, latency and resolution working very well, with no user experience issues reported.
What we’ve found that Windows is looking up the ‘wpad’ DNS entry for auto-proxy / PAC files (wpad.domainsuffix). As this entry either does not exist, isn’t available or the server is set to not-respond, the wireless environment detects this as a mixture of the following (vendor terminology differs):
· DNS server rejected a high number of queries
· DNS queries failed to be returned from server
· DNS domain does not exist
As we all transition to DNS-over-HTTPS (DoH), we imagine that vendors will remove these environment metrics as they will not be able to interrogate this data for environment details.
How can we remove these false failures from our environments? We have found that having a ‘wpad’ record successfully solves this issue by allowing the query to resolve. Further to this, so we’re not then causing confusion for the end-device, we find that setting this to 127.0.0.1 (device loopback) works successfully and does not cause any unexpected behaviour.
This ‘wpad’ record needs to be created in the DNS Search Domain that your clients receive from DHCP.
If you’re using Windows Server (2008+ onwards) DNS Service, we have found that the service is set with ‘wpad’ and ‘lsatap’ on a Query Block List. (See below reference for further information)
To allow this DNS Record to be queried you can either;
Remove ‘wpad’ from the DNS Block Query list.
In the Registry;
Remove ‘wpad’ from this entry and then restart DNS Service. After this restart, ‘wpad’ will then resolve provided you have created the DNS record in the aforementioned DNS Search Domain.
Turn off DNS Query Block List
In Administrator Command Prompt;
dnscmd /config /enableglobalqueryblocklist 0
‘wpad’ should then resolve on clients provided you have created the DNS record in the aforementioned DNS Search Domain..
From here, create a ‘wpad’ DNS record pointing to 127.0.0.1
Depending on update frequency from the wireless vendor you should see the metrics start to improve!
· If clients have a public DNS Server (EG: 220.127.116.11 or 18.104.22.168) it will not resolve ‘wpad’. This means your environment will continue flag this as a failure.
· If you are using ‘wpad’ in your environment the above will not be relevant for your particular application!
· As we move to the DoH this metric will become deprecated!
· Google Chrome still performs a lookup for 3 random 10 character hostnames on launch, to detect whether DNS hijacking is taking place (if you think of ISP’s trying to serve ads, for example), so expect these to still report issues. Further information is available here: