DNS Physical Structure

Applies To: Windows Server 2008

The logical structure of Windows Server® 2008 DNS involves DNS namespace partitioning, which extends the DNS domain name hierarchy into multiple subdomains. The physical structure of DNS involves distributing the DNS database using DNS servers to host DNS zones for the subdomains of the DNS domain name hierarchy. Both the DNS Client and Server service applications manage the physical DNS data in the DNS database.

DNS Client service

Windows Server 2008 includes a DNS Client service that is enabled by default. This service performs all required DNS lookups and provides a local cache for DNS queries that reduces DNS network traffic and speeds name resolution.

This service can be stopped and started using the Services console.

The Windows Server 2008 DNS Client service performs the following tasks:

• Registers its names in DNS.

• Performs name resolution.

• Caches responses to name resolution queries.

• Removes previously resolved names from the cache when it receives a negative response for the name.

• Performs negative caching.

• Keeps track of transitory (Plug and Play) network connections and the DNS server lists based on their IP configurations.

• Maintains connection-specific domain name suffixes.

• If multiple DNS servers are configured on the client, prioritizes which DNS servers it uses according to whether they respond to a query.

• Prioritizes the multiple A resource records it receives from a DNS server based on their IP address.

• Initiates a network failure timeout when all DNS Client service queries time out, and does not submit any queries for 30 seconds. This feature applies to every adapter separately.

Windows Server 2008 DNS client configuration involves the following settings in the TCP/IP properties for each computer:

• Domain names

• Host names

• Primary DNS suffixes

• Connection-specific names

• NetBIOS names

• DNS servers list

• DNS suffix search list

Domain names

The domain name is used with the client computer name to form the fully qualified domain name (FQDN), known also as the full computer name. In general, the DNS domain name is the remainder of the FQDN that is not used as the unique host name for the computer.

For example, if the FQDN, or full computer name, is wkstn1.example.microsoft.com; the domain name is the example.microsoft.com portion of this name.

DNS domain names have two variations — a DNS name and a NetBIOS name. The full computer name (a fully qualified DNS name) is used during querying and location of named resources on your network. For earlier version clients, the NetBIOS name is used to locate various types of NetBIOS services that are shared on your network.

An example that shows the need for both NetBIOS and DNS names is the Net Logon service. In Windows Server 2008 DNS, the Net Logon service on a domain controller registers its service (SRV) resource records on a DNS server. For Windows NT Server 4.0 and earlier versions of the operating system, domain controllers register a DomainName entry in Windows Internet Name Service (WINS) to perform the same registration and to advertise their availability for providing authentication service to the network.

When a client computer is started on the network, it uses the DNS resolver to query a DNS server for SRV records for its configured domain name. This query is used to locate domain controllers and provide logon authentication for accessing network resources. A client or a domain controller on the network optionally uses the NetBIOS resolver service to query WINS servers, attempting to locate DomainName [1C] entries to complete the logon process.

Your DNS domain names should follow the same standards and recommended practices that apply to DNS computer naming. In general, acceptable naming conventions for domain names include the use of letters A through Z, numerals 0 through 9, and the hyphen (-). The use of the period (.) in a domain name is always used to separate the discrete parts of a domain name, commonly known as labels. Each label corresponds to an additional level defined in the DNS namespace tree.

For most computers, the primary DNS suffix configured for the computer can be the same as its Active Directory domain name, although the two values can be different.

Host names

Computers using the underlying TCP/IP protocol of a Windows-based network use an IP address, a 32-bit numeric value (in the case of IPv4) or a 128-bit numeric value (in the case of IPv6), to identify the computer network connection of network hosts. However, network users prefer to use memorable, alphanumeric names. To support this need, network resources in a Windows-based network are identified by both alphanumeric names and IP addresses. DNS and WINS are two name resolution mechanisms that enable the use of alphanumeric names, and convert these names into their respective IP addresses. For example, in the FQDN wkstn1.example.microsoft.com., the DNS computer name is the label wkstn1.

NetBIOS vs. DNS computer names

In networks running Windows NT 4.0 and earlier, users typically locate and access a computer on the network using a NetBIOS (Network Basic Input Output System) name. In later versions of the Windows operating system, including Windows Server 2008, users locate and access a computer using DNS. In this implementation of DNS, a computer is identified by its full computer name, which is a DNS FQDN.

Primary DNS suffixes

The full computer name is a concatenation of the single-label host name, such as hostcomputer, and a multilabel primary DNS suffix name, such as corp.example.com, which is the DNS name of the Active Directory domain to which the computer is joined. Using the host and primary DNS suffix examples, the full computer name is hostcomputer.corp.example.com.

The host name is the same as the computer name specified during the installation of Windows Server 2008 and is listed in System Properties. The primary DNS suffix name is the same as the domain name specified during installation of Windows Server 2008 and is listed in System Properties. The full computer name is also listed in System Properties.

In addition, connection-specific DNS suffixes can be applied to the separate network adapter connections used by a multihomed computer. Connection-specific DNS suffixes identify the host when it is connected to separate networks that use different domain names. When using connection-specific DNS suffixes, a full computer name is also a concatenation of the host name and a connection-specific DNS suffix.

Using its host name and DNS suffixes, a single computer can have its full computer name configured using two possible methods:

• A primary full computer name, which applies as the default full computer name for the computer and all of its configured network connections.

• A connection-specific full computer name, which can be configured as an alternate DNS domain name that applies only for a single network adapter installed and configured on the computer.

When using Active Directory, by default, the primary DNS suffix portion of a computer’s full computer name must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator can create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Connection-specific names

As shown in the following figure, a multihomed server computer named “host-a” can be named according to both its primary and connection-specific DNS domain names.

Connection-specific DNS names

In this example, the server computer host-a attaches to two separate subnets — Subnet 1 and Subnet 2 — which are also linked at redundant points using two routers for additional paths between each subnet. Given this configuration, host-a provides access as follows through its separately named local area network (LAN) connections:

• The name “host-a.public.example.microsoft.com” provides access using LAN connection 1 over Subnet 1, a lower-speed (10 megabit) Ethernet LAN, for normal access to users who have typical file and print service needs.

• The name “host-a.backup.example.microsoft.com” provides access using LAN connection 2 over Subnet 2, a higher-speed (100 megabit) Ethernet LAN, for reserved access by server applications and administrators who need to troubleshoot server networking problems, perform network-based backup, or replicate zone data between servers.

In addition to the connection-specific DNS names, the computer can also be accessible using either of the two LAN connections by specifying its primary DNS domain name, “host-a.example.microsoft.com”.

When configured as shown, a computer can register resource records in DNS according to its three distinct names and sets of IP addresses, as shown in the following table:

DNS names

DNS Name	IP Addresses	Description
host-a.example.microsoft.com	10.1.1.11, 10.2.2.22	Primary DNS name for computer. The computer registers A and PTR resource records for all configured IP addresses under this name in the “example.microsoft.com” zone.
host-a.public.example.microsoft.com	10.1.1.11	Connection-specific DNS name for LAN connection 1, which registers A and PTR resource records for IP address 10.1.1.11 in the “public.example.microsoft.com” zone.
host-a.backup.example.microsoft.com	10.2.2.22	Connection-specific DNS name for LAN connection 2, which registers A and PTR resource records for IP address 10.2.2.22 in the “backup.example.microsoft.com” zone.

When a computer changes between connections to different networks hosting different DNS domains, the host name does not need to be changed unless there is a host in the new DNS domain with the same host name. The primary DNS suffix for the computer can be changed from the old domain name to the new domain and the computer will register the new full computer name in DNS.

In Windows Server 2008, the full computer name is viewed and set on the Computer Name tab of System Properties. Connection-specific DNS suffixes are configured in the Advanced TCP/IP Settings dialog box of the Internet Protocol (TCP/IP) Properties for a network connection.

NetBIOS names

The NetBIOS name is created using the first 16 bytes of the host name, which is the maximum number of characters for NetBIOS names. The NetBIOS name is a 16-byte string that uniquely identifies a computer or service for network communication. If the DNS host name is 15 or fewer bytes, the NetBIOS name is the host name plus enough spaces to form a 15-byte name, followed by a 1-byte unique identifier. The sixteenth byte specifies the network service associated with the computer. When the computer name exceeds the maximum length for NetBIOS, the NetBIOS computer name is created by truncating the host name to form a 15-byte name, followed by a 1-byte unique identifier.

If you are using NetBIOS names to support legacy Microsoft networking technology, it is recommended that you revise NetBIOS computer names used on your network to prepare for migration to a standard DNS-only environment. This prepares your network well for long term growth and compatibility with future naming requirements. For example, if you use the same computer name for both NetBIOS and DNS resolution, consider converting any special characters in your current NetBIOS names that do not comply with DNS naming standards, such as the underscore (_). While these characters are permitted in NetBIOS names, they are more often incompatible with traditional DNS host naming requirements and most existing DNS resolver client software.

The following table summarizes the differences between DNS and NetBIOS names using the example FQDN client1.example.com.

DNS and NetBIOS names

Name Type	Description
NetBIOS name	The NetBIOS name is used to uniquely identify the computer’s NetBIOS services. This unique NetBIOS name is resolved to the IP address of the computer through broadcast, WINS, or the LMHosts file. By default, the computer’s NetBIOS name is the same as the host name up to 15 bytes, plus any spaces required to make the name 15 bytes long, plus the service identifier. For example, a NetBIOS name might be Client1.
Host name	The host name is the first label of a FQDN. For example, the first label of the FQDN client1.example.com is client1.
Primary DNS suffix	Every computer running the Windows operating system can be assigned a primary DNS suffix to be used in name resolution and name registration. You can view the primary DNS suffix for your computer from the Computer Name tab of System Properties. The primary DNS suffix is also known as the primary domain name. For example, the FQDN client1.example.com has the primary DNS suffix example.com.
Connection-specific DNS suffix	The connection-specific DNS suffix is a DNS suffix that is assigned to a network connection. The connection-specific DNS suffix is also known as an adapter-specific DNS suffix. For example, a connection-specific DNS suffix might be acquired01-ext.com.
Fully qualified domain name (FQDN)	The FQDN is a DNS name that uniquely identifies the computer in the DNS namespace. By default, it is a concatenation of the host name, the primary DNS suffix, and a period. For example, an FQDN might be client1.example.com.
Full computer name	The full computer name is the FQDN. It is the concatenation of the host name and primary DNS suffix (or host name and connection-specific DNS suffix).

DNS servers list

For DNS clients to operate effectively, a prioritized list of DNS name servers must be configured for each computer to use when processing queries and resolving DNS names. In most cases, the client computer contacts and uses its preferred DNS server, which is the first DNS server on its locally configured list. Listed alternate DNS servers are contacted and used when the preferred server is not available. For this reason, it is important that the preferred DNS server is appropriate for continuous client use under normal conditions.

For computers running Windows XP, the DNS server list is used by clients only to resolve DNS names. When clients send dynamic updates, such as when they change their DNS domain name or a configured IP address, they might contact these servers or other DNS servers as needed to update their DNS resource records.

By default, the DNS client on Windows XP does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network (VPN) connection. By default, the Windows Server 2008 DNS Client service does not attempt dynamic update of top-level domain (TLD) zones. Any zone named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. When DNS clients are configured dynamically using a DHCP server, it is possible to have a larger list of provided DNS servers. To effectively share the load when multiple DNS servers are provided in a DHCP options-specified list, you can configure a separate DHCP scope that rotates the listed order of DNS and WINS servers provided to clients.

DNS suffix search list

For DNS clients, you can configure a DNS domain suffix search list that extends or revises their DNS search capabilities. By adding additional suffixes to the list, you can search for short, unqualified computer names in more than one specified DNS domain. Then, if a DNS query fails, the DNS Client service can use this list to append other name suffix endings to your original name and repeat DNS queries to the DNS server for these alternate FQDNs.

For computers and servers, the following default DNS search behavior is predetermined and used when completing and resolving short, unqualified names.

When the suffix search list is empty or unspecified, the primary DNS suffix of the computer is appended to short unqualified names, and a DNS query is used to resolve the resultant FQDN. If this query fails, the computer can try additional queries for alternate FQDNs by appending any connection-specific DNS suffix configured for network connections.

If no connection-specific suffixes are configured or queries for these resultant connection-specific FQDNs fail, then the client can then begin to retry queries based on systematic reduction of the primary suffix (also known as devolution).

For example, if the primary suffix were “example.microsoft.com”, the devolution process would be able to retry queries for the short name by searching for it in the microsoft.“com” and “com” domains.

When the suffix search list is not empty and has at least one DNS suffix specified, attempts to qualify and resolve short DNS names are limited to searching only those FQDNs made available by the specified suffix list. If queries for all FQDNs that are formed as a result of appending and trying each suffix in the list are not resolved, the query process fails, producing a “name not found” result.

If the domain suffix list is used, clients continue to send additional alternate queries based on different DNS domain names when a query is not answered or resolved. After a name is resolved using an entry in the suffix list, unused list entries are not tried. For this reason, it is most efficient to order the list with the most commonly used domain suffixes first.

Domain name suffix searches are used only when a DNS name entry is not fully qualified. To fully qualify a DNS name, a trailing period (.) is entered at the end of the name.

Name restrictions for hosts and domains

Different DNS implementations allow different characters and lengths, and differ from NetBIOS naming restrictions. The following table shows the restrictions for standard DNS names, DNS names in Windows Server 2008, and NetBIOS names.

Restriction	Standard DNS (Including Windows NT 4.0)	DNS in Windows Server 2008	NetBIOS
Characters	Supports RFC 1123, which permits “A” to “Z”, “a” to “z”, “0” to “9”, and the hyphen (-)	Several different configurations are possible, as described at the end of this section.	Permits Unicode characters, numbers, white space, symbols: ! @ $ % ^ & ) ( . - _ { } ~
Fully qualified domain name length	Permits 63 bytes per label and 255 bytes for an FQDN	Permits 63 bytes per label and 255 bytes for an FQDN; the FQDN for an Active Directory domain name is limited to 64 bytes.	Permits 16 bytes for a host name

Windows Server 2008 supports migration by allowing a wider character set than is specified in RFC 1123. RFC 2181 enlarges the character set allowed in DNS names. It states that a DNS label can be any binary string, and it does not necessarily need to be interpreted as ASCII. Based on this definition, Microsoft has proposed that the DNS name specification be readjusted to accommodate a larger character set: UTF-8 character encoding, as described in RFC 2044.

UTF-8 character encoding is a superset of ASCII and a translation of the UCS-2 (also known as Unicode) character encoding. The UTF-8 character set includes characters from most of the world’s written languages; this enables a far greater range of possible names. The Windows Server 2008 DNS service includes support for UTF-8 character encoding. For more information about UTF-8, see “Unicode character support” in DNS Processes and Interactions.

However, before using additional characters in DNS names, consider the following issues:

• Some other DNS client software supports only the characters listed in RFC 1123. This DNS client software might not able to resolve the DNS names of computers with names that use characters outside the set supported by RFC 1123.

• A DNS server that does not support UTF-8 encoding might accept a zone transfer of a zone containing UTF-8 names, but it cannot write back those names to a zone file or reload those names from a zone file. Therefore, you must not transfer a zone that contains UTF-8 characters to a DNS server that does not support them.

• If you attempt to register a DNS name in AD DS that contains an extended character that cannot be rendered in an LDAP distinguished name, AD DS will respond with an invalid syntax error.

  You can configure the Windows Server 2008 DNS server to allow or reject the use of UTF-8 characters in DNS names. You can do this for each DNS server administered using the DNS console.

Subnet prioritization

DNS subnet prioritization returns local IP addresses to the DNS Client service in preference to IP addresses on different subnets. This feature reduces network traffic by encouraging client computers to connect to network resources closer to them.

For example, suppose the three Web servers that host www.example.com are located on different subnets. On the DNS server, you can create the following resource records:

www.example.com.  IN A  172.16.64.11
www.example.com.  IN A  172.17.64.22
www.example.com.  IN A  172.18.64.33

When a user queries for www.example.com, all three resource records are returned. With subnet prioritization, the DNS Client service reorders the list of records returned so that it begins with the IP addresses from networks to which the computer is directly connected. For example, if a user with the IP address 172.17.64.93 queries for www.example.com, the DNS Client service returns the resource records in the following order:

www.example.com.  IN A  172.17.64.22
www.example.com.  IN A  172.16.64.11
www.example.com.  IN A  172.18.64.33

Although subnet prioritization can reduce network traffic across subnets, you might prefer to use round robin, as described in RFC 1794.

DNS Server service

The DNS Server service is the component that provides the server implementation of DNS. The settings discussed in this section include:

• Disabling the use of recursion

• Round robin use of resource records

• Subnet prioritization

• Advanced parameters

Disabling recursion

By default, recursion is enabled for the DNS Server service, and clients typically request that the server uses recursion to resolve a name when sending a query. If recursion is disabled, the DNS Server service always uses referral, regardless of the client request.

In general, DNS servers can answer queries for names outside of their authoritative zones in two ways:

• Servers can send referral answers, which are an immediate response to the requesting client with a list of resource records for other DNS servers that it knows about that appear to be closer or more likely to be of help in resolving the queried name.

• Servers can use recursion to query other servers on behalf of the requesting client, attempting to fully resolve the name. Recursive lookups continue until the server receives an authoritative answer for the queried name. The server then forwards this answer in response to the original query from the requesting client.

In most cases, recursion is disabled on a DNS server when DNS clients are limited to resolving names authoritatively managed on a specific server. For example, this is the case when a DNS server has only DNS names data for an internal network or when the DNS server is incapable of resolving external DNS names (such as Internet DNS names) and clients are expected to retry another DNS server to resolve these names.

Round robin

Round robin DNS is a method of managing server congestion by distributing connection loads across multiple servers (containing identical content). Round robin works on a rotating basis in that one server IP address is handed out, then moves to the back of the list; the next server IP address is handed out, then it moves to the end of the list; and so on, depending on the number of servers being used. This works in a looping fashion.

This local balancing mechanism is used by DNS servers to share and distribute network resource loads. You can use round robin to rotate all resource record types contained in a query answer if multiple RRs are found.

By default, DNS uses round robin to rotate the order of RR data returned in query answers where multiple RRs of the same type exist for a queried DNS domain name. This feature provides a simple method for load balancing client use of Web servers and other frequently queried multihomed computers.

If round robin is disabled for a DNS server, the order of the response for these queries is based on a static ordering of RRs in the answer list as they are stored in the zone (either its zone file or AD DS).

Example: Round-robin rotation

A forward lookup-type query (for all Host Address [A] RRs that match a DNS domain name) is made for a multihomed computer (multihomed.example.microsoft.com) that has three IP addresses. Separate A RRs are used to map the host’s name to each of these IP addresses in the zone. In the stored example.microsoft.com zone, the RRs appear in this fixed order:

multihomed   IN  A  10.0.0.1
multihomed   IN  A  10.0.0.2
multihomed   IN  A  10.0.0.3

The first DNS client that queries the server to resolve this host’s name receives the list in default order. When a second client sends a subsequent query to resolve this name, the list is rotated as follows:

multihomed   IN  A  10.0.0.2
multihomed   IN  A  10.0.0.3
multihomed   IN  A  10.0.0.1

Restricting round-robin rotation for selected RR types

By default, DNS will perform round robin rotation for all RR types. You can now specify that certain RR types are not to be round-robin rotated in the registry. These modifications can be made in the registry.

Restricting round-robin rotation for all RR types

By default, all RR types are rotated, except those that have been specified as excluded from rotation in the registry.

Subnet prioritization

By default, the DNS Server service uses local subnet prioritizing as the method for giving preference to IP addresses on the same network when a client query resolves to a host name that is mapped to more than one IP address. This feature requires that the client application attempts to connect to the host using its closest (and typically fastest) IP address available for connection.

The DNS Server service uses local subnet priority as follows:

1. The DNS Server service determines if local subnet prioritization is required to order the query response.

   If more than one A resource record (RR) matches the queried host name, the DNS Server service can reorder the records by their subnet location. If the queried host name only matches a single A resource record, or if the IP network address of the client does not match an IP network address for any of the mapped addresses in an answer list of multiple RRs, no prioritizing is required.

2. For each RR in the matched answer list, the DNS Server service determines which records (if any) match the subnet location of the requesting client.

3. The DNS Server service reorders the answer list so that A RRs that match the local subnet of the requesting client are placed first in the answer list.

4. Prioritized by subnet order, the answer list is returned to the requesting client.

Simple example: Local network prioritizing

A multihomed computer, multihomed.example.microsoft.com, has three A RRs for its three separate host IP addresses in the example.microsoft.com zone. A separate A RR is used for each of the host’s addresses, which appear in this order in the zone:

multihomed   IN  A  192.168.1.27
multihomed   IN  A  10.0.0.14
multihomed   IN  A  172.16.20.4

If a DNS client resolver at IP address 10.4.3.2 queries the server for the IP addresses of host multihomed.example.microsoft.com, the DNS Server service notes that the originating IP network address (10.0.0.0) of the client matches the network (class A) portion of the 10.0.0.4 address in the answer list of RRs. The DNS Server service then reorders the addresses in the response as follows:

multihomed   IN  A  10.0.0.14
multihomed   IN  A  192.168.1.27
multihomed   IN  A  172.16.20.4

If the IP address of the requesting client has no local network match with any of the RRs in the answer list, then the list is not prioritized.

Complex example: Local subnet prioritizing

In Windows Server 2008, addresses are prioritized by matching the class C subnet by default, regardless of the subnet mask or address class of the target address.

For example, a multihomed computer, multihomed.example.microsoft.com, has four A RRs for four separate host IP addresses in the example.microsoft.com zone. Two of these IP addresses are for nonlocal networks. The other two IP addresses share a common IP network address but, because IP subnetting is used, represent different physical subnetted network connections based on their custom (nondefault) subnet mask value of 255.255.248.0. These example RRs appear in the following order in the zone:

multihomed   IN  A  192.168.1.27
multihomed   IN  A  172.16.22.4
multihomed   IN  A  10.0.0.14
multihomed   IN  A  172.16.31.5

If the IP address of the requesting client is 172.16.22.8, both of the IP addresses that match the same IP network as the client, the 172.16.0.0 network, are returned at the top of the answer list to the client. However, in this example, the 172.16.22.4 address is placed ahead of the 172.16.31.5 address because it matches the client IP address down through the 172.16.20.0 subnet address.

The reordered answer list returned by the DNS Server service would be:

multihomed   IN  A  172.16.22.4
multihomed   IN  A  172.16.31.5
multihomed   IN  A  192.168.1.27
multihomed   IN  A  10.0.0.14

Advanced DNS Server service parameters

When initialized for service, DNS servers use server configuration settings taken from the parameters stated in a boot information file, the registry, and possibly zone information provided through AD DS integration.

In most situations, the installation defaults are acceptable and should not require modification. However, when needed, you can use the DNS console to tune the following advanced parameters, accommodating special deployment needs and situations.

DNS Server service advanced parameters

Value	Description
Disable recursion	Determines whether the DNS server uses recursion. By default, the DNS Server service is enabled to use recursion.
BIND secondaries	Determines whether to use fast transfer format when transferring a zone to DNS servers running legacy Berkeley Internet Name Domain (BIND) implementations. By default, all Windows-based DNS servers use a fast zone transfer format, which uses compression and can include multiple records per TCP message during a connected transfer. This format is also compatible with more recent BIND-based DNS servers that run versions 4.9.4 and later.
Fail on load if bad zone data	Sets the DNS server to parse files strictly. By default, the DNS Server service logs data errors, ignores any erred data in zone files, and continues to load a zone. This option can be reconfigured using the DNS console so that the DNS Server service logs errors and fails to load a zone file containing records data that is determined to have errors.
Enable round robin	Determines whether the DNS server uses round robin to rotate and reorder a list of resource records if multiple RRs of the same type exist for a query answer.
Enable netmask ordering	Determines whether the DNS server reorders A resource records within the same resource record set in its response to a query based on the IP address of the source of the query.
Secure cache against pollution	Determines whether the server attempts to clean up responses to avoid cache pollution. This setting is enabled by default. By default, DNS servers use a secure response option that eliminates adding unrelated resource records included in a referral answer to their cache. In most cases, any names added in referral answers are typically cached and help expedite the speed of resolving subsequent DNS queries. With this feature, however, the server can determine that referred names are potentially polluting or insecure and discard them. The server determines whether to cache the name offered in a referral on the basis of whether it is part of the exact related DNS domain name tree for which the original queried name was made. For example, if a query was originally made for “example.microsoft.com” and a referral answer provided a record for a name outside of the “microsoft.com” domain name tree, such as msn.com, then that name would not be cached if this feature is enabled for use.

Resource records in DNS

DNS resource records are the data that is associated with DNS names in the DNS namespace. Each domain name of the DNS namespace tree contains a set of resource records, and each resource record in the set contains different types of information relating to the domain name. A DNS query includes the DNS domain name that is to be resolved and the type of information desired (the resource records that are requested). Queries for the IP addresses of DNS hosts return A resource records, and queries for the DNS servers authoritative for a DNS domain name return name server (NS) resource records.

Resource records are typically discussed in two categories: authority records and other records. Authority records identify the DNS servers that are authoritative for the domain names in the DNS namespace and how their zones should be managed, and all other DNS records contain information about a domain name that is unrelated to authority.

Authority records

Zones are based on a concept of server authority. When a DNS server is configured to load a zone, it uses two types of resource records to determine the authoritative properties of the zone:

• First, the Start of Authority (SOA) resource record indicates the name of origin for the zone and contains the name of the server that is the primary source for information about the zone. It also indicates other basic properties of the zone.

• Next, the name server (NS) resource record is used to notate which DNS servers are designated as authoritative for the zone. By listing a server in the NS RR, it becomes known to others as an authoritative server for the zone. This means that any server specified in the NS RR is to be considered an authoritative source by others, and is able to answer with certainty any queries made for names included in the zone.

The SOA and NS resource records occupy a special role in zone configuration. They are required records for any zone and are typically the first resource records listed in files.

SOA resource record

The Start of Authority (SOA) resource record is always first in any standard zone. It indicates the DNS server that either originally created it or is now the primary server for the zone. It is also used to store other properties such as version information and timings that affect zone renewal or expiration. These properties affect how often transfers of the zone are performed between servers authoritative for the zone.

The SOA resource record contains the following information:

SOA resource record fields

Field	Description
Primary server (owner)	The host name for the primary DNS server for the zone.
Responsible person	The e-mail address of the person responsible for administering the zone. A period (.) is used instead of an at sign (@) in this e-mail name.
Serial number	The revision number of the zone file. This number increases each time a resource record in the zone changes. It is important that this value increases each time the zone is changed, so that either partial zone changes or the fully revised zone can be replicated to other secondary servers during subsequent transfers.
Refresh interval	The time, in seconds, that a secondary DNS server waits before querying its source for the zone to attempt renewal of the zone. When the refresh interval expires, the secondary DNS server requests a copy of the current SOA record for the zone from its source, which answers this request. The secondary DNS server then compares the serial number of the source server’s current SOA record (as indicated in the response) with the serial number in its own local SOA record. If they are different, the secondary DNS server requests a zone transfer from the primary DNS server. The default for this field is 900 seconds (15 minutes).
Retry interval	The time, in seconds, a secondary server waits before retrying a failed zone transfer. Normally, this time is less than the refresh interval. The default value is 600 seconds (10 minutes).
Expire interval	The time, in seconds, before a secondary server stops responding to queries after a lapsed refresh interval where the zone was not refreshed or updated. Expiration occurs because at this point in time, the secondary server must consider its local data unreliable. The default value is 86,400 seconds (24 hours).
Minimum (default) TTL	The default Time-To-Live (TTL) of the zone and the maximum interval for caching negative answers to name queries. The default value is 3,600 seconds (1 hour).

The following is an example of a default SOA resource record:

@   IN  SOA     nameserver.example.microsoft.com.  postmaster.example.microsoft.com. (
                               1            ; serial number
                               3600         ; refresh   [1h]
                               600          ; retry     [10m]
                               86400        ; expire    [1d]
                               3600 )       ; min TTL   [1h]

In the preceding example SOA record, the primary or originating server for the zone is shown as nameserver.example.microsoft.com. The e-mail address for the person to contact regarding questions about this zone is postmaster.example.microsoft.com.

Periods are used to represent e-mail addresses when writing and storing DNS domain names in a zone. In an e-mail application, the previous example address would instead likely appear as postmaster@example.microsoft.com. The parentheses used in the SOA resource record as it appears in a zone file are used to enable wrapping of the record over multiple lines of text. If an individual TTL value is assigned and applied to a specified resource record used in the zone, it overrides the minimum (default) TTL set in the SOA record.

NS resource record

Name server (NS) resource records can be used to assign authority to specified servers for a DNS domain name in two ways:

• By establishing a list of authoritative servers for the domain so that those servers can be made known to others that request information about this domain (zone).

• By indicating authoritative DNS servers for any subdomains that are delegated away from the zone.

In the case of assigning servers with host names in the same zone, corresponding address (A) resource records are normally used in the zone to resolve the names of specified servers to their IP addresses. For servers that are specified using this RR as part of a zone delegation to a subdomain, the NS resource record usually contains out-of-zone names. For the out-of-zone names to be resolved, A resource records for the specified out-of-zone server’s might be needed. When these out-of-zone NS and A records are needed to provide delegation, they are known as glue records.

The following table shows the basic syntax of how a NS RR is used.

Basic syntax of a NS resource record

Description: Used to map a DNS domain name as specified in owner to the name of hosts operating DNS servers specified in the name_server_domain_name field.

Syntax:owner ttlINNSname_server_domain_name.

Example: example.microsoft.com.    IN NS nameserver1.example.microsoft.com

Other important records

After a zone is created, additional resource records must be added to it. The following table lists the most common resource records (RRs) to be added.

Common DNS resource records

Resource Record	Description
Host (A)	For mapping a DNS domain name to an IP address used by a computer.
Alias (CNAME)	For mapping an alias DNS domain name to another primary or canonical name.
Mail Exchanger (MX)	For mapping a DNS domain name to the name of a computer that exchanges or forwards mail.
Pointer (PTR)	For mapping a reverse DNS domain name based on the IP address of a computer that points to the forward DNS domain name of that computer.
Service location (SRV)	For mapping a DNS domain name to a specified list of DNS host computers that offer a specific type of service, such as Active Directory domain controllers.

Host (A) resource records

Host (A) resource records are used in a zone to associate DNS domain names of computers (or hosts) to their IP addresses. Host (A) resource records can be added manually. Windows clients and servers can also use the DHCP Client service to dynamically register and update their own A resource records in DNS when an IP configuration change occurs. DHCP-enabled client computers running earlier versions of Windows operating systems can have their A resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server.

The host (A) resource record is not required for all computers, but is needed by computers that share resources on a network. Any computer that shares resources and must be identified by its DNS domain name, must use A resource records to provide DNS name resolution to the IP address for the computer.

Most A RRs that are required in a zone can include other workstations or servers that share resources, other DNS servers, mail servers, and Web servers. These resource records make up most of the resource records in a zone database.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical names. These records allow you to use more than one name to point to a single host, making it easy to do such things as host both an FTP server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using CNAME RRs that map to the DNS host name, such as “server-1” for the server computer that hosts these services.

CNAME RRs are recommended for use in the following scenarios:

• When a host specified in an A RR in the same zone needs to be renamed.

• When a generic name for a well-known server such as www needs to resolve to a group of individual computers (each with individual A RRs) that provides the same service. An example would be a group of redundant Web servers.

When renaming a computer with an existing A RR in the zone, you can use a CNAME RR temporarily, to allow a grace period for users and programs to switch from specifying the old computer name to using the new one. To do this, you need the following:

• For the new DNS domain name of the computer, a new A RR is added to the zone.

• For the old DNS domain name, a CNAME RR is added that points to the new A RR.

• The original A RR for the old DNS domain name (and its associated PTR RR, if applicable) is removed from the zone.

When using a CNAME RR for aliasing or renaming a computer, set a temporary limit on how long the record is used in the zone before removing it from DNS. If you forget to delete the CNAME RR and later its associated A RR is deleted, the CNAME RR can waste server resources by trying to resolve queries for a name no longer used on the network.

The most common use of a CNAME RR is to provide a permanent DNS aliased domain name for generic name resolution of a service-based name, such as www.example.microsoft.com, to more than one computer or one IP address used in a Web server. For example, the following shows the basic syntax of how a CNAME RR is used.

alias_name IN CNAME primary_canonical_name

In this example, a computer named host-a.example.microsoft.com needs to function as both a Web server named “www.example.microsoft.com.” and an FTP server named “ftp.example.microsoft.com.”. To achieve the intended use for naming this computer, you can add and use the following CNAME entries in the example.microsoft.com zone:

host-a    IN  A      10.0.0.20 ftp       IN  CNAME  host-a www       IN  CNAME  host-a 

If you later decide to move the FTP server to another computer, separate from the Web server on “host-a”, simply change the CNAME RR in the zone for ftp.example.“microsoft.com” and add an additional A RR to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer were named “host-b.example.microsoft.com”, the new and revised A and CNAME RRs would be as follows:

host-a    IN  A      10.0.0.20 host-b    IN  A      10.0.0.21 ftp       IN  CNAME  host-b www       IN  CNAME  host-a 

Mail exchanger (MX) resource records

The mail exchanger (MX) RR is used by e-mail applications to locate a mail server based on a DNS domain name used in the destination address for the e-mail recipient of a message. For example, a DNS query for the name example.microsoft.com could be used to find an MX RR, enabling an e-mail application to forward or exchange mail to a user with the e-mail address user@microsoft.com.

The MX RR shows the DNS domain name for the computer or computers that process mail for a domain. If multiple MX RRs exist, the DNS Client service attempts to contact mail servers in the order of preference from lowest value (highest priority) to highest value (lowest priority). The following shows the basic syntax for use of an MX RR.

mail_domain_name IN MX preference mailserver_host 

By using the MX RRs shown below in the example.microsoft.com zone, mail addressed to user@example.microsoft.com is delivered to user@mailserver0.example.microsoft.com first, if possible. If this server is unavailable, the resolver client can then use user@mailserver1.example.microsoft.com instead.

@         IN  MX   1    mailserver0 @         IN  MX   2    mailserver1 

The use of the at sign (@) in the records indicates that the mailer DNS domain name is the same as the name of origin (example.microsoft.com) for the zone.

Pointer (PTR) resource records

Pointer (PTR) RRs are used to support the reverse lookup process, based on zones created and rooted in the in-addr.arpa domain. These records are used to locate a computer by its IP address and resolve this information to the DNS domain name for that computer.

PTR RRs can be added to a zone in several ways:

• You can manually create a PTR RR for a static TCP/IP client computer using the DNS Client service, either as a separate procedure or as part of the procedure for creating an A RR.

• Computers use the DHCP Client service to dynamically register and update their PTR RR in DNS when an IP configuration change occurs.

• All other DHCP-enabled client computers can have their PTR RRs registered and updated by the DHCP server if they obtain their IP lease from a qualified server.

The pointer (PTR) resource record is used only in reverse lookup zones to support reverse lookup.

Service location (SRV) resource records

To locate Active Directory domain controllers, service location (SRV) RRs are required. Typically, you can avoid manual administration of the SRV RR when installing AD DS.

By default, the Active Directory installation wizard attempts to locate a DNS server based on the list of preferred or alternate DNS servers, configured in any of its TCP/IP client properties, for any of its active network connections. If a DNS server that can accept dynamic update of the SRV RR (and other RRs related to registering Active Directory as a service in DNS) is contacted, the configuration process is complete.

If, during the installation, a DNS server that can accept updates for the DNS domain name used to name your Active Directory is not found, the wizard can install a DNS server locally and automatically configure it with a zone to support the Active Directory domain.

For example, if the Active Directory domain that you chose for your first domain in the forest was example.microsoft.com, a zone rooted at the DNS domain name of example.microsoft.com would be added and configured to use the DNS server running on the new domain controller.

Whether or not you install the DNS Server service locally, a file (Netlogon.dns) is written and created during the AD DS installation process that contains the SRV RRs and other RRs required to support the use of AD DS. This file is created in the systemroot\System32\Config folder.

If you are using a DNS server that fits one of the following descriptions, you should use the records in Netlogon.dns to manually configure the primary zone on that server to support AD DS.

• The computer operating your DNS server is running on another platform, such as UNIX, and cannot accept or recognize dynamic updates.

• A DNS server at this computer that is not the DNS Server service provided with the Windows Server 2008 operating system is authoritative for the primary zone corresponding to the DNS domain name for your Active Directory domain.

• The DNS server supports the SRV RR, as defined in the Internet draft, “A DNS RR specifying the location of services (DNS SRV)”, but does not support dynamic updates. For example, the DNS Server service provided with Windows NT Server 4.0, when updated to Service Pack 4 or later, fits this description.

In the future, the SRV RR might also be used to register and look up other well-known TCP/IP services on your network if applications implement and support DNS name queries that specify this record type.

Other additional resource records are supported by Windows Server 2008 DNS and are used less frequently in most zones. These additional types of resource records can be added as needed using the DNS console. For more information about supported resource records, see DNS Reference Information.

DNS-related files

The following files relate to using and configuring DNS servers and clients.

File	Description
Boot	BIND boot configuration file. This file is not created by the DNS console. However, as an optional configuration for the DNS Server service, it can be copied from another DNS server running the Berkeley Internet Name Domain (BIND) server implementation of DNS. To use this file with the DNS Server service, you need to click From file in Server properties. On BIND servers, this file is often called the “named.boot” file.
Cache.dns	Used to preload resource records into the DNS server names cache. DNS servers use this file to help locate root servers on either your network or the Internet. By default, this file contains DNS resource records that prime the local cache of the server with the addresses of authoritative root servers for the Internet. If you are setting up a DNS server to resolve Internet DNS names, the information in this file is required unless you enable the use of another DNS server as a forwarder to resolve these names. Traffic to the Internet root servers is heavy, but because host names are not usually resolved at this level, the load can be reasonably handled. Instead, the root hints file provides referral information that can be useful during DNS name resolution to redirect a query to other servers that are authoritative for names located beneath the root. For DNS servers operating privately on your internal network, the DNS console can learn and replace the contents of this file with internal root servers on your network, provided they are reachable through the network when you are setting up and configuring new DNS servers. It can be updated using the DNS console from the Root Hints tab located under the applicable server properties. This file preloads the server names cache when it is started.
Root.dns	Root zone file. This file can appear at a DNS server if it is configured as a root server for your network.
zone_name.dns	Used when a standard zone (either primary or secondary) is added and configured for the server. Files of this type are not created or used for primary type zones that are directory-integrated, which are stored in the Active Directory database.

These files can be found in the systemroot\System32\Dns folder on the server computer.

Zones and zone transfer

DNS distributes the DNS namespace database using DNS zones, which store name information about one or more DNS domains. There are three types of DNS zones supported in Windows Server 2008:

• Primary zone. Original copy of a zone where all resource records are added, modified, and deleted.

• Secondary zone. Read-only copy of the primary zone that is created and updated by transferring zone data from the primary zone.

• Stub zone. Read-only copy of the primary zone containing only the DNS resource records for the DNS servers listed in the zone (SOA, NS, and glue A resource records).

Difference between zones and domains

A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or belong to another zone. After a subdomain is added, it can then either be managed and included as part of the original zone records, or delegated away to another zone created to support the subdomain.

For example, the following figure shows the microsoft.com domain, which contains domain names for Microsoft. When the microsoft.com domain is first created at a single server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however, the microsoft.com domain needs to use subdomains, those subdomains must be included in the zone or delegated away to another zone.

DNS Domain Names and Subdomain Names

In this example, the example.microsoft.com domain shows a new subdomain — the example.microsoft.com domain — delegated away from the microsoft.com zone and managed in its own zone. However, the microsoft.com zone needs to contain a few resource records to provide the delegation information that references the DNS servers that are authoritative for the delegated example.microsoft.com subdomain.

If the microsoft.com zone does not use delegation for a subdomain, any data for the subdomain remains part of the microsoft.com zone. For example, the subdomain dev.microsoft.com is not delegated away, but is managed by the microsoft.com zone.

Why zone replication and zone transfers are needed

Because of the important role that zones play in DNS, it is intended that they be available from more than one DNS server on the network, to provide availability and fault tolerance when resolving name queries. Otherwise, if a single server is used and that server is not responding, queries for names in the zone can fail. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.

When a new DNS server is added to the network and is configured as a new secondary server for an existing zone, it performs a full initial transfer of the zone to obtain and replicate a full copy of resource records for the zone. For most earlier DNS server implementations, this same method of full transfer for a zone is also used when the zone requires updating after changes are made to the zone. For DNS servers running Windows Server 2008, the DNS service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes.

Domain delegation

A subordinate domain name, or subdomain, can be delegated from the DNS zone where its parent name is stored to a zone on another DNS server. When deciding whether to delegate your DNS namespace to make additional zones, consider the following reasons to use additional zones:

• A need to delegate management of part of your DNS namespace to another location or department within your organization.

• A need to divide one large zone into smaller zones for distributing traffic loads among multiple servers.

• A need to extend the namespace by adding numerous subdomains at once, such as to accommodate the opening of a new branch or site.

If, for any of these reasons, you could benefit from delegating subordinate domain names to additional zones, it might make sense to restructure your namespace by adding additional zones. When choosing how to structure zones, you should use a plan that reflects the structure of your organization.

When delegating zones within your namespace, be aware that for each new zone you create, you will need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is required both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers being made authoritative for the new zone.

When a standard primary zone is first created, it is stored as a text file containing all resource record information about a single DNS server. This server acts as the primary master for the zone. Zone information can be replicated to other DNS servers to improve fault tolerance and server performance.

When structuring your zones, there are several good reasons to use additional DNS servers for zone replication:

• Additional DNS servers provide zone redundancy, enabling DNS names in the zone to be resolved for clients if a primary server for the zone stops responding.

• Additional DNS servers can be placed so as to reduce DNS network traffic. For example, adding a DNS server to the opposing side of a low-speed wide area network (WAN) link can be useful in managing and reducing network traffic.

• Additional DNS secondary servers can be used to reduce loads on a primary server for a zone.

Example: Delegating a subdomain to a new zone

As shown in the following figure, when a new zone for a subdomain (example.microsoft.com) is created, delegation from the parent zone (microsoft.com) is required.

Delegating a Subdomain

In this example, an authoritative DNS server computer for the newly delegated example.microsoft.com subdomain is named based on a derivative subdomain included in the new zone (ns1.na.example.microsoft.com). To make this server known to others outside of the new delegated zone, two RRs are needed in the microsoft.com zone to complete delegation to the new zone:

• An NS RR to advertise that the server named ns1.na.example.microsoft.com is an authoritative server for the delegated subdomain.

• An A RR (also known as a glue record) to resolve the name of the server specified in the NS RR to its IP address. The process of resolving the host name in this RR to the delegated DNS server in the NS RR is sometimes referred to as glue chasing.

Incremental zone transfers

Incremental zone transfers are described in RFC 1995 as an additional DNS standard for replicating DNS zones. When incremental transfers are supported by both a DNS server acting as the source for a zone and any servers that copy the zone from it, the incremental transfer provides a more efficient method of propagating zone changes and updates.

In earlier DNS implementations, any request for an update of zone data required a full transfer of the entire zone database using an AXFR query. With incremental transfer, an alternate query type (IXFR) can be used instead. This allows the secondary server to pull only those zone changes it needs to synchronize its copy of the zone with its source, either a primary or secondary copy of the zone maintained by another DNS server.

With IXFR zone transfers, differences between the source and replicated versions of the zone are first determined. If the zones are identified to be the same version — as indicated by the serial number field in the SOA resource record of each zone — no transfer is made.

If the serial number for the zone at the source is greater than at the requesting secondary server, a transfer is made of only those changes to RRs for each incremental version of the zone. For an IXFR query to succeed and changes to be sent, the source DNS server for the zone must keep a history of incremental zone changes to use when answering these queries. The incremental transfer process requires substantially less traffic on a network and zone transfers are completed much faster.

Example: Zone transfer

A zone transfer might occur during any of the following scenarios:

• When the refresh interval expires for the zone.

• When a secondary server is notified of zone changes by its master server.

• When the DNS Server service is started at a secondary server for the zone.

• When the DNS console is used at a secondary server for the zone to manually initiate a transfer from its master server.

Zone transfer requests are always initiated at the secondary server for a zone, and then sent to their configured master servers which act as their source for the zone. Master servers can be any other DNS server that loads the zone, such as either the primary server for the zone or another secondary server. When the master server receives the request for the zone, it can reply with either a partial or full transfer of the zone to the secondary server.

Zone transfer process

As shown in the following figure, zone transfers between servers follow an ordered process. This process varies, depending on whether a zone has been previously replicated, or if initial replication of a new zone is being performed.

Zone Transfer Process

1. During new configuration, the destination server sends an initial “all zone” transfer (AXFR) request to the master DNS server configured as its source for the zone.

2. The master (source) server responds and fully transfers the zone to the secondary (destination) server.

   The zone is delivered to the destination server requesting the transfer with its version established by use of a Serial number field in the properties for the Start of Authority RR. The SOA RR also contains a stated refresh interval in seconds (by default, 900 seconds or 15 minutes) to indicate when the destination server should next request to renew the zone with the source server.

3. When the refresh interval expires, an SOA query is used by the destination server to request renewal of the zone from the source server.

4. The source server answers the query for its SOA record.

   This response contains the serial number for the zone in its current state at the source server.

   The destination server checks the serial number of the SOA record in the response and determines how to renew the zone.

   If the value of the serial number in the SOA response is equal to its current local serial number, it concludes that the zone is the same at both servers and that a zone transfer is not required. The destination server then renews the zone by resetting its refresh interval based on the value of this field in the SOA response from its source server.

   If the value of the serial number in the SOA response is higher than its current local serial number, it concludes that the zone has been updated and that a transfer is required.

5. If the destination server concludes that the zone has changed, it sends an IXFR query to the source server, containing its current local value for the serial number in the SOA record for the zone.

6. The source server responds with either an incremental or full transfer of the zone.

   If the source server supports incremental transfer by maintaining a history of recent incremental zone changes for modified resource records, it can answer with an IXFR of the zone.

   If the source server does not support incremental transfer, or does not have a history of zone changes, it can answer with a full (AXFR) transfer of the zone instead.

DNS Notify

Windows-based DNS servers support DNS Notify, an update to the original DNS protocol specification that permits a means of initiating notification to secondary servers when zone changes occur (RFC 1996). DNS notification implements a push mechanism for notifying a select set of secondary servers for a zone when the zone is updated. Servers that are notified can then initiate a zone transfer as described above, to pull zone changes from their master servers and update their local replicas of the zone.

For secondaries to be notified by the DNS server acting as their configured source for a zone, each secondary server must first have its IP address in the notify list of the source server. When using the DNS console, this list is maintained in the Notify dialog box, which is accessible from the Zone Transfer tab located in zone Properties.

In addition to notifying the listed servers, the DNS console permits you to use the contents of the notify list as a means to restrict or limit zone transfer access to only those secondary servers specified in the list. This can help prevent an undesired attempt by an unknown or unapproved DNS server to pull, or request, zone updates.

DNS notification process

The following is a brief summary of the typical DNS notification process for zone updates:

• The local zone at a DNS server acting as a master server, a source for the zone to other servers, is updated. When the zone is updated at the master or source server, the serial number field in the SOA RR is also updated, indicating a new local version of the zone.

• The master server sends a DNS notify message to other servers that are part of its configured notify list.

• All secondary servers that receive the notify message can then respond by initiating a zone transfer request back to the notifying master server.

The normal zone transfer process can then continue as described in the previous section.

You cannot configure a notify list for a stub zone.

Use DNS notification only to notify servers operating as secondary servers for a zone. For replication of directory-integrated zones, DNS notification is not required. This is because any DNS servers that load a zone from AD DS automatically poll the directory (as specified by the SOA resource record’s refresh interval) to update and refresh the zone. In these cases, configuring a notify list can actually degrade system performance by causing unnecessary additional transfer requests for the updated zone.

Stub zones

A stub zone is a copy of a zone that contains only those resource records required to identify the authoritative DNS servers for that zone. A stub zone is used to resolve names between separate DNS namespaces. The need for this type of resolution can occur when a corporate merger requires that the DNS servers for two separate DNS namespaces resolve names for clients in both namespaces.

A stub zone consists of:

• The SOA resource record, NS resource records, and the glue A resource records for the delegated zone.

• The IP address of one or more master servers that can be used to update the stub zone.

The master servers for a stub zone are one or more DNS servers authoritative for the child zone, usually the DNS server hosting the primary zone for the delegated domain name.

Stub zone resolution

When a DNS client performs a recursive query operation on a DNS server hosting a stub zone, the DNS server uses the resource records in the stub zone to resolve the query. The DNS server sends an iterative query to the authoritative DNS servers specified in the NS resource records of the stub zone as if it were using NS resource records in its cache. If the DNS server cannot find the authoritative DNS servers in its stub zone, the DNS server hosting the stub zone attempts standard recursion using its root hints.

The DNS server will store the resource records it receives from the authoritative DNS servers listed in a stub zone in its cache, but it will not store these resource records in the stub zone itself; only the SOA, NS, and glue A resource records returned in response to the query are stored in the stub zone. The resource records stored in the cache are cached according to the TTL value in each resource record. The SOA, NS, and glue A resource records, which are not written to cache, expire according to the expire interval specified in the stub zone’s SOA record, which is created during the creation of the stub zone and updated during transfers to the stub zone from the original, primary zone.

If the query was an iterative query, the DNS server returns a referral containing the servers specified in the stub zone.

Stub zone updates

Stub zone updates involve the following conditions:

• When a DNS server loads a stub zone, it queries the zone’s master server for the SOA resource record, NS resource records at the zone’s root, and glue A resource records.

• During updates to the stub zone, the master server is queried by the DNS server hosting the stub zone for the same resource record types requested during the loading of the stub zone.

• The refresh interval of the SOA resource record determines when the DNS server hosting the stub zone will attempt a zone transfer (update).

• If an update fails, the retry interval of the SOA resource record determines when the update is retried.

• After the retry interval has expired without a successful update, the expiration time, as specified in the Expires field of the SOA RR, determines when the DNS server stops using the stub zone data.

Root hints

Root hints are used to prepare servers authoritative for non-root zones so that they can learn and discover authoritative servers that manage domains located at a higher level or in other subtrees of the DNS domain namespace. These hints are essential for servers authoritative at lower levels of the namespace when locating and finding servers under these conditions.

For example, suppose a DNS server (Server A) has a zone called sub.example.microsoft.com. In the process of answering a query for a higher-level domain, such as the example.microsoft.com domain, Server A needs some assistance to locate an authoritative server (such as Server B) for this domain.

In order for Server A to find Server B, or any other servers that are authoritative for the microsoft.com domain, it needs to be able to query the root servers for the DNS namespace. The root servers can then refer Server A to the authoritative servers for the com domain. The servers for the com domain can, in turn, offer referral to Server B or other servers that are authoritative for the microsoft.com domain.

The root hints used by Server A must have helpful hints to the root servers for this process to locate Server B (or another authoritative server) as intended.

To configure and use root hints correctly, first determine how the following applies to your DNS servers:

• Are you using DNS on the Internet or on a private network?

• Is the server used as a root server?

By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the systemroot\System32\Dns folder on the server computer. This file normally contains the NS and A resource records for the Internet root servers. If, however, you are using the DNS Server service on a private network, you can edit or replace this file with similar records that point to your own internal root DNS servers.

Another server configuration in which root hints are treated differently is one in which a DNS server is configured to be used by other DNS servers in an internal namespace as a forwarder for any DNS queries of names managed externally (the Internet, for example). Even though the DNS server used as a forwarder can be located internally on the same network as servers using it as a forwarder, it needs hints for the Internet root servers to work properly and resolve external names.

EDNS0

Extension Mechanisms for DNS (EDNS0, as defined in RFC 2671) allow DNS requestors to advertise the size of their UDP packets and facilitate the transfer of packets larger than 512 octets, the original DNS restriction for UDP packet size (RFC 1035). When a DNS server receives a request over the UDP transport layer, it identifies the requestor’s UDP packet size from the option (OPT) RR and scales its response to contain as many resource records as are allowed in the maximum UDP packet size specified by the requestor.

In Windows Server 2008, DNS support for EDNS0 is enabled by default. It can be disabled using the registry. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters

Add the entry EnableEDNSProbes to the subkey. Give the entry a DWORD value and set it to 0x0 to disable EDNS0.

Use extreme caution when editing the registry. Modifications to the registry are not validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can result in unrecoverable errors in the system.

For more information about resource records, see DNS Reference Information.

ENDS0 UDP responses

Before a DNS server assumes that the requestor supports EDNS0, the DNS server must receive a query containing an OPT resource record. An OPT record contains no actual DNS data and its contents relate to the UDP transport layer message only. The OPT record stores the sender’s UDP payload size in its CLASS field and lists the number of octets in the largest UDP payload that the requestor can deliver in the requestor’s network.

When the DNS server receives a query containing an OPT record advertising the maximum UDP packet size, it will truncate any UDP response’s size larger than the limit specified in the OPT record.

By default, the DNS server includes OPT resource records indicating its UDP maximum in responses to queries containing OPT resource records.

If the DNS server receives a query that does not contain an OPT resource record, it assumes the requestor’s server does not support EDNS0 and will respond to the requestor assuming that the sender does not accept UDP packets larger than 512 octets. In this case, the DNS server will truncate its UDP response size to a maximum of 512 octets.

EDNS0 UDP queries

Before the requesting DNS server sends a query, it checks its cache to identify if the responding DNS server supports EDNS0. If the responding DNS server supports EDNS0, the requesting DNS server attaches an OPT resource record to the additional section of the query it sends. (All queries have five sections: header, question, answer, authority, and additional.) If, according to the requesting DNS server’s cache, the responding DNS server does not support EDNS0, the requesting DNS server will not attach an OPT resource record to the query before it is sent.

Identifying and caching EDNS0 support

When the DNS server receives a request or response from a host containing an OPT record, the DNS server caches the EDNS version supported by the host (such as EDNS0). If there is no OPT record in a request or response from a host, the DNS server’s cache will indicate that the host does not support EDNS0. If the cache already indicates that the host supports ENDS0, then cache will not be changed.

The default value for how long a host’s EDNS0 support information is cached is 86400 (one day, specified in seconds). This value can be modified in the registry.

The DNS server determines that a host does not support EDNS0 when it requests an OPT resource record and receives a response containing one of the following response code (RCODE) values in the header, as shown in the following table.

EDNS0 failure code values

Name	Value	Description
FORMERR	1	Format Error. The name server did not interpret the OPT resource record.
SERVFAIL	2	Server Failure. The name server did not process the query because of a problem with the name server.
NOTIMPL	4	Not Implemented. The name server does not support the kind of query requested.

(The RCODE field is a 4-bit field set in the header section as part of responses.) In this situation (as a requester), the DNS server determines that the server does not support EDNS0 and caches this information.

DNSSEC

Windows Server 2008 DNS provides basic support of the DNS Security Extensions (DNSSEC) protocol, as defined in RFC 2535. The current feature support allows DNS servers to perform as secondary DNS servers for existing DNSSEC–compliant, secure zones. DNS supports the storing and loading of the DNSSEC-specific resource records. Currently, a DNS server is not capable of signing zones and resource records (creating cryptographic digital signatures) or validating the SIG RRs. The DNSSEC resource records are KEY, SIG, and NXT. For more information about resource records, see DNS Reference Information.

Server support for DNSSEC

When loading a zone containing DNSSEC resource records, the DNS server loads these records along with all other types of resource records contained in the zone. When receiving a zone transfer containing DNSSEC resource records (SIG, KEY, NXT), the DNS server writes these records to the zone storage (zone data file or Active Directory database) along with all other resource records.

When a DNS server receives a request or response containing DNSSEC resource records, it does not verify the digital signatures, but caches the response and uses it for ensuing queries. When a DNS server receives a request for a resource record in a zone also containing DNSSEC resource records, it attaches the appropriate DNSSEC records to the response.

When a signed zone contains resource records for an owner name, including a CNAME resource record for that name, the DNS server will return the DNSSEC resource records associated with the owner name and the CNAME resource record’s alias name. The DNS server will not suppress the retrieval of the CNAME resource record, and it will not return a SIG resource record for the canonical name. Rather, it will return the SIG resource record for the alias name.

Client support for DNSSEC

The DNS client does not read and store a key for the trusted zone and, consequently, it does not perform any cryptography, authentication, or verification. When a resolver initiates a DNS query and the response contains DNSSEC resource records, programs running on the DNS client will return these records and cache them in the same manner as any other resource records. This is the extent to which DNS clients running Windows XP and Windows Vista support DNSSEC. When the DNS client receives the SIG RR relating to the RRset, it will not perform an additional query to obtain the associated KEY record or any other DNSSEC records.

Resolvers do not authenticate resource records by verifying the signature information contained in the SIG resource record. The DNS client does not contain any information to indicate which resource records have been authenticated or to what extent they have been authenticated.

When a resolver receives a response or performs a query operation, it does not recognize the checking disabled (CD) query header bit, which in DNSSEC indicates that the data is authenticated by the server according to its policies, nor does it set the authentic data query header bit, which in DNSSEC indicates that unauthenticated data is acceptable to the resolver.

Active Directory integration

The DNS Server service is integrated into the design and implementation of AD DS, which provides an enterprise-level tool for organizing, managing, and locating resources in a network.

In addition to supporting a conventional way of maintaining and replicating DNS zone files, the implementation of DNS in Windows Server 2008 has the option of using AD DS as the data storage and replication engine for DNS. DNS is the domain controller location mechanism for AD DS.

Benefits of integrating DNS with AD DS

Active Directory integration provides numerous benefits, including fault tolerance, security, simplified management, and more efficient replication of zones.

Using AD DS as the data storage and replication engine provides the following benefits:

• DNS replication is performed by AD DS, so there is no need to support a separate replication topology for DNS servers.

• Active Directory service replication provides per-property replication.

• Active Directory service replication is secure.

• A primary DNS server is eliminated as a single point of failure. Original DNS replication is single-master and relies on a primary DNS server to update all the secondary servers. Unlike original DNS replication, Active Directory service replication is multimaster; an update can be made to any domain controller in it, and the change will be propagated to other domain controllers. In this way, if DNS is integrated into Active Directory service, the replication engine will always synchronize the DNS zone information.

Thus Active Directory integration significantly simplifies the administration of a DNS namespace. At the same time, standard zone transfers to other DNS servers (DNS servers other than Windows 2000 Server, Windows Server 2003 and Windows Server 2008 DNS servers, as well as earlier versions of Microsoft DNS servers) are still supported.

How DNS integrates with AD DS

When you install AD DS on a server, you promote the server to the role of a domain controller for a specified domain. When completing this process, you are prompted to specify a DNS domain name for the Active Directory domain for which you are joining and promoting the server.

If during this process, a DNS server authoritative for the domain that you specified either cannot be located on the network or does not support the DNS dynamic update protocol, you are prompted with the option to install a DNS server. This option is provided because a DNS server is required to locate this server or other domain controllers for members of an Active Directory domain.

After you have installed AD DS, you have two options for storing and replicating your zones when operating the DNS server at the new domain controller:

• Standard zone storage, using a text-based file.

  Zones stored this way are located in .dns files that are stored in the systemroot\System32\Dns folder on each computer operating a DNS server. Zone file names correspond to the name you choose for the zone when creating it, such as “example.microsoft.com.dns” if the zone name is “example.microsoft.com.”

• Directory-integrated zone storage, using the Active Directory database.

  Zones stored this way are located in the Active Directory tree under the domain or application directory partition. Each directory-integrated zone is stored in a dnsZone container object identified by the name you choose for the zone when creating it.

Zones stored in text files are typically referred to as file-backed zones and zones stored in AD DS are referred to as Active Directory-integrated zones.

In Active Directory-integrated DNS, each DNS zone becomes an Active Directory container object (DnsZone). The DnsZone object contains a DnsNode leaf object for every unique name within that zone. The DnsNode object has a DnsRecord multivalued attribute with an instance of a value for every record associated with the object’s name.

Replication model

When DNS zone information is stored in AD DS and an update is made to a DNS server, it writes the update data to AD DS. AD DS is now responsible for replicating the data to other domain controllers. The DNS servers running on other domain controllers will poll the updates from AD DS.

Because Active Directory service uses the multimaster replication model, DNS updates can be written to any Active Directory-integrated DNS server, and the data will automatically be replicated across all the domain controllers.

The ability to write to AD DS from multiple domain controllers at the same time can create a conflicting situation where the changes are made to the same object on two different DNS servers. The conflict will eventually be resolved in favor of the last update made to the object based on the timestamps of the updates. The same rule is applied in the case where two or more nodes with the same name are created on two or more DNS servers. Until the conflict is resolved and the DNS server, containing invalid update, polls the valid data from the Active Directory, it is possible that requests for the same object made to two different DNS servers will be resolved differently. This is why the Active Directory database is called loosely consistent.

Active Directory-integration provides an advantage over file-backed zones. With file-backed zones, only the primary authoritative DNS server for a zone can modify the zone. With Active Directory-integration, all domain controllers for the Active Directory domain where the zone is stored can modify the zone and then replicate the changes to other domain controllers. This replication process is called multimaster replication because multiple domain controllers can update the zone.

Windows Server 2008 domain controllers replicate resource records contained in Active Directory–integrated zones using Active Directory replication. Zones stored in AD DS can also be transferred to secondary servers to create secondary zones in the same way that file-backed zones are transferred.

Active Directory-integrated zones

When you configure a primary zone to be Active Directory–integrated, the zone is stored in AD DS.

The following figure shows this configuration.

Active Directory–integrated zone

The DNS server component contains only a copy of the zone. When DNS starts, it reads a copy of the zone from the Active Directory database (step 1). Then, when the DNS server receives a change, it writes the change to the Active Directory database (step 2).

Through Active Directory replication, the zone is replicated to other domain controllers in the same domain. Also, through standard zone transfer, the DNS server can send its copy of the zone to any secondary DNS servers that request it. The DNS server can perform both incremental and full zone transfers. The following figure shows how the same zone can be replicated by using both Active Directory replication and standard zone transfer.

Active Directory replication and zone transfer

By default, when the DNS Server service starts on a domain controller, it checks whether AD DS is available and if it contains any DNS zones. If AD DS has zones, the DNS Server service loads them. The DNS Server service automatically writes back to the boot file at regular intervals. The boot file can be updated manually by using the DNS console.

The DNS Server service also loads the root hints and server and zone parameters from different locations, depending on its settings. The following table shows the locations from which the DNS Server service loads and to which it writes zones, root hints, and server and zone parameters.

How the DNS server loads zones, root hints, and parameters

Task	Load Data On Startup Set To: From File	Load Data On Startup Set To: From Registry	Load Data On Startup Set To: From Active Directory and Registry
Read root hints from:	Root hints file	If available, the root hints file. Otherwise, if the directory is available and contains root hints, the directory.	If the directory is available and contains root hints, from the directory. Otherwise, from the root hints file.
Write root hints to:	Root hints file	Root hints file.	If the directory is available, the directory.
Read zones from:	Boot file, to get list of zones, then from zone files	Registry	The directory (for Active Directory–integrated zones) and the registry.
Write zones to:	Boot file and the registry	Registry and, if the zone is Active Directory–integrated, the directory.	Registry and, if the zone is Active Directory–integrated, the directory.
Read server and zones parameters from:	Boot file and the registry	Registry and (for Active Directory–integrated zones) the directory.	The directory (for Active Directory–integrated zones) and the registry.
Write server and zones parameters to:	Boot file and the registry	Registry (for all zones) and (for Active Directory–integrated zones) the directory	The directory (for Active Directory–integrated zones) and the registry

If you change the setting of the DNS Server service, it first writes the root hints file, zones, and parameters to the locations specified in the default setting, and then the DNS Server service reads them from the new setting.

Directory-integrated zone storage location

AD DS is an object-oriented X.500-compliant database that organizes resources available on your network in a hierarchical tree-like structure. This database is managed by a set of domain controllers. The portion of the Active Directory database for which a specific domain controller is authoritative is physically located on the same computer as the domain controller. Every Active Directory resource is represented by an object. There are two distinct types of objects supported by AD DS:

• Containers–objects that can contain other container and leaf objects.

• Leafs–objects representing a specific resource within the Active Directory service tree.

Each Active Directory object has attributes associated with it that define particular characteristics of the object.

The classes of objects in the Active Directory database, as well as the attributes of each object, are defined in the Active Directory schema. In other words, the schema contains definitions for each class object available in AD DS. The following are examples of Active Directory service class objects:

• User

• Group

• Organizational Unit

• DnsZone

• DnsNode

In Windows 2000 Server, Active Directory-integrated zones were stored in the domain partition of the directory. Zones stored in the domain partition are replicated to all domain controllers in the domain. This replication scope is not required for some applications, such as DNS. Windows Server 2008 Active Directory provides a type of partition, called application directory partition, to enable different replication scopes. Application directory partitions provide storage for application-specific data that can be replicated to any arbitrary set of domain controllers in the forest, as few or as many as required by the application that uses the data.

There are two default Windows Server 2008 DNS application directory partitions created to allow for different DNS zone replication scopes: the forest-wide DNS application directory partition and the domain-wide application directory partition. Active Directory-integrated zones can be stored in the domain or application directory partitions. The following table describes the Windows Server 2008 Active Directory storage options available for DNS zones.

Windows Server 2008 Active Directory storage options

Active Directory Storage Option	Description
Domain partition	Active Directory domain partition for each domain in the forest. DNS zones stored in this partition are replicated to all domain controllers in the domain. This is the only Active Directory storage option for DNS zones that are replicated to domain controllers running Windows 2000 Server.
Forest-wide DNS application directory partition	DNS application directory partition for the entire forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the forest. This DNS application directory partition is created when you install the DNS Server service on the first Windows Server 2008 domain controller in the forest.
Domain-wide DNS application directory partition	DNS application directory partition for each domain in the forest. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers in the domain. For the forest root domain, this DNS application directory partition is created when you first install the DNS Server service on a Windows Server 2008 domain controller in the forest. For each new domain in the forest (child domain), this DNS application directory partition is created when you first install the DNS Server service on a Windows Server 2008 domain controller for the new domain.
Custom DNS application directory partition	DNS application directory partition for any domain controller that is enlisted in its replication scope. This type of DNS application directory partition does not exist by default and must be created. DNS zones stored in this application directory partition are replicated to all DNS servers running on domain controllers that enlist in the partition.

Active Directory DNS objects

By default, Windows Server 2008 Active Directory-integrated zones are stored in the domain-wide application directory partition of the directory. The zone information is stored with the container whose distinguished name is: CN=MicrosoftDNS,DC=DNS domain name. The zone information for zones stored on domain controllers in the example.com domain would be stored in CN=MicrosoftDNS,DC=DomainDnsZones,DC=example,DC=com.

The DNS application directory partitions are not displayed by all Active Directory administrative tools. To see these directory partitions, you can use dnscmd (command-line tool) or ADSI Edit (adsiedit.msc) in Support Tools.

The replication scope of a custom DNS application directory partition is defined by the number of domain controllers enlisted in the partition. By default, only members of the Enterprise Admins group can enlist a DNS server in a DNS application directory partition.

After a DNS server is enlisted in a DNS application directory partition, you can store DNS zones in that application directory partition using the DNS console. The required FQDN value specifies the name of the new DNS application directory partition. You must use a DNS fully qualified domain name.

The MicrosoftDNS container holds other objects that represent the zones and the individual DNS resource records in those zones. The following table lists the DNS object types that are stored in the Active Directory database.

Object	Description
DnsZone	Container created when a zone is stored in the Active Directory database.
DnsNode	Leaf object used to map and associate a name in the zone to resource data.
DnsRecord	Multivalued attribute of a dnsNode object used to store the resource records associated with the named node object.
DnsProperty	Multivalued attribute of a dnsZone object used to store zone configuration information.

The MicrosoftDNS container object contains one or more dnsZone container objects. Each dnsZone object represents one zone.

MicrosoftDNS contains the following dnsZone objects:

• The reverse lookup zone, 72.16.172.in-addr.arpa

• The forward lookup zone

• The root hints, RootDNSServers

You can view DNS objects from within the Active Directory Users and Computers console.

The dnsZone container object contains a dnsNode leaf object for every unique name within that zone. Following is a list of dnsNode objects within the dnsZone container object:

• @, which signifies that the node has the same name as the dnsZone object.

• delegated, a delegated subdomain.

• host.notdelegated, a host in the domain notdelegated.com, a domain that is controlled by the zone on the root domain.

• host1, a host in the domain.

• mailserver, the mail server in the domain.

• nameserver, the name server.

• notdelegated, the domain notdelegated.com, which is controlled by the zone on the root domain.

The dnsNode leaf object has a multivalued attribute called dnsRecord with an instance of a value for every record associated with the object’s name.

Although you can view the zone objects from within the Active Directory Users and Computers component, the Active Directory Users and Computers component cannot interpret the values of the dnsRecord attribute. If you want to view the DNS domain hierarchy and associated records, use the DNS console. Alternatively, if you want to view the zones, you can retrieve them by using Nslookup.