Many times on the Web boards you’ll see me ask “can the client resolve unqualified names?” in response to a question related to name resolution, often when the problem is due to VPN client name resolution. Why do I ask these questions and what does this have to do with WPAD?
First we need to define what an unqualified name is. An unqualified name is essentially a single-label name. For example, take the following URL:
server1 is a single label name and is unqualified because there is no domain information in the name. We could qualify the name by using the following URL:
When a name is fully qualified, that name can be sent to a DNS server for name resolution. A DNS server is not able to answer queries for unqualified names because it cannot determine if it is authoritative for that name. The question is then how is it that we are able to get away with using unqualified names on our corporate networks when using accessing internal servers?
We are able to use unqualified names on the internal network to reach internal network servers because the operating system is able to append the machine’s primary DNS suffix to the request before the query is forwarded to the DNS server. For example, when you enter http://server1 into the browser, the operating system’s DNS client software is able to append the primary DNS suffix to the request and then forward it to the DNS server for name resolution. If the machine is a member of the msfirewall.org domain, then the DNS query request is for server1.msfirewall.org.
You can see the primary DNS suffix by right clicking the My Computer icon on the desktop and then clicking Properties. Click the Computer Name tab. Click the Change button then click the More button. You’ll see the DNS Suffix and NetBIOS Computer Name dialog box. Here you see the Primary DNS suffix of this computer text box and the Change primary DNS suffix when domain membership changes checkbox. When the machine is a domain member, it automatically uses the domain name for it’s DNS suffix. That’s why you can resolve single-label, unqualified host names on the internal network.
This also explains why VPN users often have problems with name resolution when they dial-in. They expect their non-domain joined computers to work the same away as their workstations and try to access internal computers using unqualified names, just like when they’re in the office. The problem is that their laptops aren’t joined to the domain and either have no primary DNS suffix configured, or perhaps one from another domain. You can fix this problem by manually adding a DNS suffix, or assigning one via DHCP to the VPN clients (this will require that you install a DHCP relay on the ISA firewall because domain name suffix assignment is a DHCP option).
So what does all of this have to do with WPAD? When a Web proxy or Firewall client uses autodiscovery to find the ISA firewall, it sends a request for http://wpad. The Web browser and Firewall client have no knowledge of the machine’s domain name, but the client resolver on the operating system does, and fully qualifies the name before sending a DNS query. This allows the machine to send a DNS query for wpad.domain.com instead of just wpad. We know that send a single label name to a DNS server won’t work and that’s why we need to take advantage of the DNS client to fully qualify the name for us.
In DNS, you need to have a Host (A) record for the ISA firewall so that the ISA firewall can resolve it’s own name. You can then create a CNAME record for wpad.domain.com and point it to the Host (A) record for the ISA firewall. Or, if you don’t want to use a CNAME record, you can just create a Host (A) for wpad.domain.com and map it to the IP address on the internal interface of the ISA firewall. This might be a better solution is a multinetworked ISA firewall with multiple internal Networks, as I’m not sure what the effect of CNAME records would be on netmask ordering to support multiple wpad entries.
Thomas W Shinder, M.D.
MVP — ISA Firewalls