Export (0) Print
Expand All

Managing the Global Query Block List

Updated: May 9, 2008

Applies To: Windows Server 2008

The dynamic update feature of Domain Name System (DNS) makes it possible for DNS client computers to register and dynamically update their resource records with a DNS server whenever a client changes its network address or host name. This reduces the need for manual administration of zone records. This convenience comes at a cost, however, because any authorized client can register any unused host name, even a host name that might have special significance for certain applications. This can allow a malicious user to take over a special name and divert certain types of network traffic to that user's computer.

Two commonly deployed protocols are particularly vulnerable to this type of takeover: the Web Proxy Automatic Discovery Protocol (WPAD) and the Intra-site Automatic Tunnel Addressing Protocol (ISATAP). Even if a network does not deploy these protocols, clients that are configured to use them are vulnerable to the takeover that DNS dynamic update enables. To help prevent such a takeover, the DNS server role in Windows Server 2008 includes a global query block list that can help prevent a malicious user from taking over DNS names that have special significance.

Most Web browsers use WPAD to locate and apply configuration settings that make it possible for the Web browsers to use a network proxy server. These configuration settings are contained in a file that is located on a server. A browser locates this server by querying a Dynamic Host Configuration Protocol (DHCP) server for the URL of the network's WPAD server. If this query is not successful, the browser attempts to locate the WPAD server by using standard DNS name-resolution queries.

For example, if the Web browser is running on a Windows-based computer named laptop.acctg.corp.contoso.com, the browser attempts to find the WPAD configuration file by looking for the following URLs:

  • http://wpad.acctg.corp.contoso.com/wpad.dat

  • http://wpad.corp.contoso.com/wpad.dat

  • http://wpad.contoso.com/wpad.dat

When the browser locates the Wpad.dat file at any of these locations, it reads the contents of the file and then configures itself according to the settings in the file.

Unfortunately, you cannot secure this automatic discovery process. Any computer that is registered in a DNS zone with the name wpad can provide a WPAD configuration to clients on the network, even if the file contains settings that cause the clients to use a fake proxy server, for example, to divert the client's Web browser to counterfeit Web sites. The dynamic update feature of DNS makes it possible for a malicious user to accomplish this without requiring the intervention of a DNS system administrator simply by giving a computer the name wpad and then connecting it to the network. As long as there is no other computer in the zone with the same name, the computer of the malicious user can register its name with the DNS server that is authoritative for its zone and then direct all WPAD queries to itself.

The block list feature that is provided by the DNS server role in Windows Server 2008 helps prevent the takeover of WPAD by ensuring that queries for WPAD servers always fail unless WPAD is excluded from the block list.

ISATAP provides a transition between networks that are based on IP version 4 (IPv4) and networks that are based solely on the newer IP version 6 (IPv6). ISATAP provides this transition by using a tunneling approach to carry IPv6 traffic on an IPv4 infrastructure. In other words, ISATAP encapsulates IPv6 packets with an IPv4 header, which makes it possible for the IPv6 packets to be transmitted through a single ISATAP router from one ISATAP-enabled host to another. This transmission occurs wherever the hosts are located on the network, regardless of whether the hosts are located on an IPv6-enabled subnet or on an IPv4-only network.

ISATAP does not support automatic router discovery. Instead, ISATAP hosts use a potential routers list (PRL) to discover available ISATAP routers. Most commonly, ISATAP hosts construct their PRLs by using DNS to locate a host named isatap on the local domain. For example, if the local domain is corp.contoso.com, an ISATAP-enabled host queries DNS to obtain the IPv4 address of a host named isatap.corp.contoso.com.

Consequently, a malicious user can spoof an ISATAP router in much the same way as a malicious user can spoof a WPAD server: A malicious user can use dynamic update to register the user's own computer as a counterfeit ISATAP router and then divert traffic between ISATAP-enabled computers on the network. To prevent this, the Windows Server 2008 DNS Server service blocks name resolution of the isatap host name by default.

In its default configuration, the Windows Server 2008 DNS Server service maintains a list of names that, in effect, it ignores when it receives a query to resolve the name in any zone for which the server is authoritative. To accomplish this, the DNS Server service first checks queries against the list. Then, if the leftmost portion of the name matches an entry in the list, the DNS Server service replies to the query as though no resource record existed, even if there is a host (A or AAAA) resource record in the zone for the name. In this way, if a host (A or AAAA) resource record exists in the zone because a host has used dynamic update to register itself with a blocked name, the DNS Server service does not resolve the name.

The block list automatically applies to all zones for which the server is authoritative. For example, if the DNS server is authoritative for contoso.com and for europe.contoso.com, it ignores queries for wpad.contoso.com as well as for wpad.europe.contoso.com. However, the DNS Server service does not ignore queries for names in zones for which it is not authoritative. Specifically, the DNS Server service does not ignore queries that it receives through a forwarder or a stub zone or as a result of normal recursion or forwarding. If the block list causes the DNS Server service to ignore a request for a resource record that does exist in a zone, it logs an event that explains why it did so. This event is logged only once after the DNS server has been restarted to prevent the event log from being flooded by an attempted denial-of-service attack.

ImportantImportant
All DNS servers that are authoritative for a zone must be running Windows Server 2008, and they must be configured with the same block list to ensure consistent results when clients query for resolution of names in the block list. The block list is a per-server setting and is not replicated between servers.

Because the DNS Server service applies the block list for all resource records, not just host (A or AAAA) resource records, it ignores queries for such resource record types as mail exchanger (MX) and service locator (SRV) resource records. However, because the DNS Server service does not apply the block list to zone names themselves, an administrator can create a zone named wpad.contoso.com, for example, and add host resource records to that zone. In this case, the DNS Server service continues to resolve host names in the wpad.contoso.com zone.

The initial contents of the block list depend on whether WPAD or ISATAP is already deployed when you add the DNS server role to an existing Windows Server 2008 deployment or when you upgrade an earlier version of Windows Server running the DNS Server service. You can use the procedures in this task to view and update the contents of the global query block list as well as to enable or disable the global query block list.

To complete this task, you can perform the following procedures:

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft