DNS Server Role
Applies To: Windows Server 2008
Domain Name System (DNS) is a system for naming computers and network services that is organized into a hierarchy of domains. TCP/IP networks, such as the Internet, use DNS to locate computers and services through user-friendly names.
To make using network resources easier, name systems such as DNS provide a way to map the user-friendly name for a computer or service to other information that is associated with that name, such as an IP address. A user-friendly name is easier to learn and remember than the numeric addresses that computers use to communicate over a network. Most people prefer to use a user-friendly name—for example, sales.fabrikam.com—to locate an e-mail server or Web server on a network rather than an IP address, such as 157.60.0.1. When a user enters a user-friendly DNS name in an application, DNS services resolve the name to its numeric address.
What does a DNS server do?
A DNS server provides name resolution for TCP/IP-based networks. That is, it makes it possible for users of client computers to use names rather than numeric IP addresses to identify remote hosts. A client computer sends the name of a remote host to a DNS server, which responds with the corresponding IP address. The client computer can then send messages directly to the remote host's IP address. If the DNS server does not have an entry in its database for the remote host, it can respond to the client with the address of a DNS server that is more likely to have information about that remote host, or it can query the other DNS server itself. This process can take place recursively until either the client computer receives the IP address or it is established that the queried name does not belong to a host within the specific DNS namespace.
The DNS server in the Windows Server® 2008 operating system complies with the set of Requests for Comments (RFCs) that define and standardize the DNS protocol. Because the DNS Server service is RFC-compliant and it can use standard DNS data file and resource record formats, it can work successfully with most other DNS server implementations, such as DNS implementations that use the Berkeley Internet Name Domain (BIND) software.
In addition, the DNS server in Windows Server 2008 provides the following special benefits in a Windows®-based network:
Support for Active Directory® Domain Services (AD DS)
DNS is required for support of AD DS. If you install the Active Directory Domain Services role on a server, you can automatically install and configure a DNS server if a DNS server that meets AD DS requirements cannot be located.
DNS zones can be stored in the domain or application directory partitions of AD DS. A partition is a data container in AD DS that distinguishes data for different replication purposes. You can specify in which Active Directory partition to store the zone and, consequently, the set of domain controllers among which that zone's data will be replicated.
In general, use of the Windows Server 2008 DNS Server service is strongly recommended for the best possible integration and support of AD DS and enhanced DNS server features. You can, however, use another type of DNS server to support AD DS deployment.
Stub zones
DNS running on Windows Server 2008 supports a zone type called a stub zone. A stub zone is a copy of a zone that contains only the resource records that are necessary to identify the authoritative DNS servers for that zone. A stub zone keeps a DNS server hosting a parent zone aware of the authoritative DNS servers for its child zone. This helps maintain DNS name-resolution efficiency.
Integration with other Microsoft networking services
The DNS Server service provides integration with other services, and it contains features that go beyond the features that are specified in the DNS RFCs. These features include integration with other services, such as AD DS, Windows Internet Name Service (WINS), and Dynamic Host Configuration Protocol (DHCP).
Improved ease of administration
The DNS snap-in in Microsoft Management Console (MMC) offers a graphical user interface (GUI) for managing the DNS Server service. Also, there are several configuration wizards for performing common server administration tasks. In addition to the DNS console, other tools are provided to help you better manage and support DNS servers and clients on your network.
RFC-compliant dynamic update protocol support
Clients can use the DNS Server service to dynamically update resource records, based on the dynamic update protocol (RFC 2136). This improves DNS administration by reducing the time needed to manage these records manually. Computers running the DNS Client service can register their DNS names and IP addresses dynamically. In addition, the DNS Server service and DNS clients can be configured to perform secure dynamic updates, a capability that enables only authenticated users with appropriate rights to update resource records on the server. Secure dynamic updates are available only for zones that are integrated with AD DS.
Support for incremental zone transfer between servers
Zone transfers replicate information about a portion of the DNS namespace among DNS servers. Incremental zone transfers replicate only the changed portions of a zone, which conserves network bandwidth.
Conditional forwarders
The DNS Server service extends a standard forwarder configuration with conditional forwarders. A conditional forwarder is a DNS server on a network that forwards DNS queries according to the DNS domain name in the query. For example, a DNS server can be configured to forward all the queries that it receives for names ending with sales.fabrikam.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.
Who will be interested in this server role?
All but the simplest TCP/IP networks require access to one or more DNS servers to function properly. Without name resolution and the other services that are provided by DNS servers, client access to remote host computers would be prohibitively difficult. For example, without access to a DNS server, browsing the World Wide Web would be virtually impossible: the vast majority of hypertext links that are published on the Web use the DNS name of Web hosts rather than their IP addresses. The same principle applies to intranets because computer users rarely know the IP addresses of computers on their local area network (LAN).
Consider deploying the DNS Server service in Windows Server 2008 if your network contains any of the following:
Domain-joined computers
Windows-based, DHCP-client computers
Computers that are connected to the Internet
Branch offices or domains that are located on a wide area network (WAN)
Are there any special considerations?
If you want to integrate the DNS Server service with AD DS, you can install DNS at the same time that you install AD DS, or you can install DNS after you install AD DS and then integrate DNS as a separate step. You can install file-backed DNS servers (that is, DNS servers that are not integrated with AD DS) on any computers in the network. Of course, you must take into consideration your network topology and traffic distribution when you decide where to deploy your DNS servers.
What new functionality does this server role provide?
The DNS Server service in Windows Server 2008 includes a number of new and enhanced features compared to the DNS Server service that was available in the Microsoft® Windows NT® Server, Windows 2000 Server, and Windows Server® 2003 operating systems. The following sections describe these features.
Background zone loading
Very large organizations with extremely large zones that store their DNS data in AD DS sometimes discover that restarting a DNS server can take an hour or more while the DNS data is retrieved from the directory service. The result is that the DNS server is effectively unavailable to service client requests for the entire time that it takes to load AD DS-based zones.
A DNS server running Windows Server 2008 now loads zone data from AD DS in the background while it restarts so that it can respond to requests for data from other zones. When the DNS server starts, it:
Enumerates all zones to be loaded.
Loads root hints from files or AD DS storage.
Loads all file-backed zones, that is, zones that are stored in files rather than in AD DS.
Begins responding to queries and remote procedure calls (RPCs).
Spawns one or more threads to load the zones that are stored in AD DS.
Because the task of loading zones is performed by separate threads, the DNS server is able to respond to queries while zone loading is in progress. If a DNS client requests data for a host in a zone that has already been loaded, the DNS server responds with the data (or, if appropriate, a negative response) as expected. If the request is for a node that has not yet been loaded into memory, the DNS server reads the node's data from AD DS and updates the node's record list accordingly.
Why is this functionality important?
The DNS server can use background zone loading to begin responding to queries almost immediately when it restarts, instead of waiting until its zones are fully loaded. The DNS server can respond to queries for the nodes that it has loaded or that can be retrieved from AD DS. This functionality also provides another advantage when zone data is stored in AD DS rather than in a file: AD DS can be accessed asynchronously and immediately when a query is received, while file-based zone data can be accessed only through a sequential read of the file.
Support for IPv6 addresses
IP version 6 (IPv6) specifies addresses that are 128 bits long, compared to IPv4 addresses, which are 32 bits long. This greater address length allows for a much larger number of globally unique addresses to accommodate the explosive growth of the Internet around the world.
DNS servers running Windows Server 2008 now support IPv6 addresses as fully as they support IPv4 addresses. For example, in the DNS snap-in, wherever an IP address is typed or displayed, the address can take the form of an IPv4 address or an IPv6 address. The dnscmd command-line tool also accepts addresses in either format. In addition, DNS servers can now send recursive queries to IPv6-only servers, and the server forwarder list can contain both IPv4 and IPv6 addresses. DHCP clients can also register IPv6 addresses in addition to (or instead of) IPv4 addresses. Finally, DNS servers now support the ip6.arpa domain namespace for reverse mapping.
Why is this functionality important?
The IPv6 addressing protocol is emerging as an important factor in the growth of the Internet. Support for IPv6 addressing in Windows Server 2008 ensures that DNS servers will be able to support present and future DNS clients that are designed to take advantage of the benefits of IPv6 addresses.
How should I prepare for this change?
Because DNS servers can now return both IPv4 host (A) resource records and IPv6 host (AAAA) resource records in response to queries, make sure that DNS client software on your network can handle such responses appropriately. It might be necessary to upgrade or replace older DNS client software to ensure compatibility with this change.
Read-only domain controller support
Windows Server 2008 introduces a new type of domain controller, the read-only domain controller (RODC). An RODC provides, in effect, a shadow copy of a domain controller that cannot be directly configured, which makes it less vulnerable to attack. You can install an RODC in locations where physical security for the domain controller cannot be guaranteed.
To support RODCs, a DNS server running Windows Server 2008 supports a new type of zone, the primary read-only zone (also sometimes referred to as a branch office zone). When a computer becomes an RODC, it replicates a full read-only copy of all of the application directory partitions that DNS uses, including the domain partition, ForestDNSZones and DomainDNSZones. This ensures that the DNS server running on the RODC has a full read-only copy of any DNS zones stored on a centrally located domain controller in those directory partitions. The administrator of an RODC can view the contents of a primary read-only zone; however, the administrator can change the contents only by changing the zone on the centrally located domain controller.
Why is this functionality important?
AD DS relies on DNS to provide name-resolution services to network clients. The changes to the DNS Server service are required to support AD DS on an RODC.
GlobalNames zone
Today, many Microsoft customers deploy WINS in their networks. As a name-resolution protocol, WINS is often used as a secondary name-resolution protocol alongside DNS. WINS is an older protocol, and it uses NetBIOS over TCP/IP (NetBT). Therefore, it is approaching obsolescence. However, organizations continue to use WINS because they appreciate having the static, global records with single-label names that WINS provides.
So that organizations can move to an all-DNS environment (or to provide the benefits of global, single-label names to all-DNS networks), the DNS Server service in Windows Server 2008 now supports a zone called GlobalNames to hold single-label names. In typical cases, the replication scope of this zone is the entire forest, which ensures that the zone has the desired effect of providing unique, single-label names across the entire forest. In addition, the GlobalNames zone can support single-label name resolution throughout an organization that contains multiple forests when you use Service Location (SRV) resource records to publish the location of the GlobalNames zone.
Unlike WINS, the GlobalNames zone is intended to provide single-label name resolution for a limited set of host names, typically corporate servers and Web sites that are centrally (IT) managed. The GlobalNames zone is not intended to be used for peer-to-peer name resolution, such as name resolution for workstations, and dynamic updates in the GlobalNames zone are not supported. Instead, the GlobalNames zone is most commonly used to hold CNAME resource records to map a single-label name to a fully qualified domain name (FQDN). In networks that are currently using WINS, the GlobalNames zone usually contains resource records for IT-managed names that are already statically configured in WINS.
When the GlobalNames zone is deployed, single-label name resolution by clients works as follows:
The client's primary DNS suffix is appended to the single-label name, and the query is submitted to the DNS server.
If that FQDN does not resolve, the client requests resolution using its DNS suffix search lists (such as those specified by Group Policy), if any.
If none of those names resolve, the client requests resolution using the single-label name.
If the single-label name appears in the GlobalNames zone, the DNS server hosting the zone resolves the name. Otherwise, the query fails over to WINS.
No changes to client software are required to enable single-label name with this feature.
The GlobalNames zone provides single-label name resolution only when all authoritative DNS servers are running Windows Server 2008. However, other DNS servers (that is, servers that are not authoritative for any zone) can be running other operating systems. Of course, the GlobalNames zone must be the only zone with that name in the forest.
To provide maximum performance and scalability, it is recommended that the GlobalNames zone be integrated with AD DS and that each authoritative DNS server be configured with a local copy of the GlobalNames zone. AD DS integration of the GlobalNames zone is required to support deployment of the GlobalNames zone across multiple forests.
Global Query block list
Most TCP/IP networks support the dynamic update feature of DNS because dynamic update is convenient for network administrators and users alike. Dynamic update 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, especially for clients that frequently move or change locations and use DHCP to obtain an IP address. This convenience comes at a cost, however, because an 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 "hijack" a special name and divert certain types of network traffic to that user's computer.
Two commonly deployed protocols are particularly vulnerable to hijacking in this fashion: the Web Proxy Auto-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 hijacking that DNS dynamic update enables. To prevent such hijacking, the DNS server role in Windows Server 2008 includes a global query block list that can help prevent a malicious user from hijacking DNS names that have special significance.
In its default configuration, the DNS Server service in Windows Server 2008 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 host (AAAA) resource record in the zone for the name. In this way, if a host (A) or host (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 initial contents of the block list depend on whether WPAD or ISATAP are already deployed when you add the DNS Server role to an existing Windows Server 2008 deployment or upgrade an earlier version of Windows Server running the DNS Server service. Also, by using the dnscmd command-line tool, you can add or remove entries from the list or turn off enforcement of the block list altogether. All DNS servers that are authoritative for a zone must be running Windows Server 2008 and must be configured with the same block list to ensure consistent results when clients query for resolution of names in the block list.
DNS client changes
Although not a direct consequence of changes to DNS for the DNS server role, the Windows Vista® and Windows Server 2008 operating systems introduce additional features to DNS client software, as described in the following sections.
LLMNR
DNS client computers can use link-local multicast name resolution (LLMNR), also known as multicast DNS or mDNS, to resolve names on a local network segment when a DNS server is not available. For example, if a router fails, cutting a subnet off from all DNS servers on the network, clients on the subnet that supports LLMNR can continue to resolve names on a peer-to-peer basis until the network connection is restored.
In addition to providing name resolution in case of network failure, LLMNR can also be useful in establishing ad hoc, peer-to-peer networks, for example, in an airport waiting area.
Changes to the ways in which clients locate domain controllers
In unusual circumstances, the way that DNS clients locate domain controllers can have an impact on network performance:
The DC Locator component of a client computer running Windows Vista or Windows Server 2008 periodically searches for a domain controller in the domain to which it belongs. This functionality helps avoid performance problems that might occur when a client locates its domain controller during a period of network failure, thereby associating the client with a distant domain controller located on a slow link. Previously, this association continued until the client was forced to seek a new domain controller, for example, when the client computer was disconnected from the network for a long period of time. By periodically renewing its association with a domain controller, a client can now reduce the probability that it will be associated with an inappropriate domain controller.
A client computer running Windows Vista or Windows Server 2008 can be configured (programmatically, with a registry setting, or by Group Policy) to locate the nearest domain controller instead of searching randomly. This functionality can improve network performance in networks containing domains that exist across slow links. However, because locating the nearest domain controller can itself have a negative impact on network performance, this functionality is not enabled by default.