DNS

Domain Name System (DNS) is the name resolution protocol for TCP/IP networks, such as the Internet. A DNS server hosts the information that enables client computers to resolve memorable, alphanumeric DNS names to the IP addresses that computers use to communicate with each other. The following topics describe the DNS server role in the Windows Server® 2008 operating system, and they provide procedures for installing, configuring, and managing DNS servers in your network.

  • DNS Overview

  • Checklist: Add a Domain Controller with the DNS Server Service

  • Checklist: Store Data in an AD DS Application Partition

  • Checklist: Use Forwarders

  • Checklist: Automatically Remove Stale Resource Records

  • Checklist: Create an Alias (CNAME) Record

  • Checklist: Use Resource Records

  • Checklist: Secure Your DNS Server

  • Checklist: Configure DNS Client Settings

  • Checklist: Migrate a DNS Server

  • Checklist: Create a Reverse Lookup Zone

  • Installing and Configuring Servers

  • Managing Servers and Zones

  • Adding Zones

  • Configuring Zone Properties

  • Managing Resource Records

  • Managing Clients

  • Securing DNS

  • Troubleshooting DNS

  • DNS Tools

  • User Interface: DNS Server


New Features in DNS for Windows Server 2008 R2

Because DNS is often subject to man-in-the-middle, spoofing, and cache-poisoning attacks that are hard to defend against, the DNS server and client in Windows Server® 2008 R2 introduce support for Domain Name System Security Extensions (DNSSEC). In short, DNSSEC allows for a DNS zone and all the records in the zone to be cryptographically signed. When a DNS server hosting a signed zone receives a query, it returns the digital signatures in addition to the records queried for. A resolver or another server can obtain the public key of the public/private key pair and validate that the responses are authentic and have not been tampered with. In order to do so, the resolver or server must be configured with a trust anchor for the signed zone, or for a parent of the signed zone.

The core DNSSEC extensions are specified in RFCs 4033, 4034, and 4035 and add origin authority, data integrity, and authenticated denial of existence to DNS. In addition to several new concepts and operations for both the DNS server and the DNS client, DNSSEC introduces four new resource records (DNSKEY, RRSIG, NSEC, and DS) to DNS.

The following changes are available in DNS server in Windows Server 2008 R2:

  • Ability to sign a zone and host signed zones.

  • Support for changes to the DNSSEC protocol.

  • Support for DNSKEY, RRSIG, NSEC, and DS resource records.

The following changes are available in DNS client in Windows Server 2008 R2:

  • Ability to indicate knowledge of DNSSEC in queries.

  • Ability to process the DNSKEY, RRSIG, NSEC, and DS resource records.

  • Ability to check whether the DNS server with which it communicated has performed validation on the client’s behalf.

The DNS client’s behavior with respect to DNSSEC is controlled through the Name Resolution Policy Table (NRPT), which stores settings that define the DNS client’s behavior. The NRPT is typically managed through Group Policy.

Additional references

  • What’s New in DNS (http://go.microsoft.com/fwlink/?LinkId=139322)


DNS Overview

Domain Name System (DNS) is a system for naming computers and network services that is organized into a hierarchy of domains. DNS naming is used in TCP/IP networks, such as the Internet, to locate computers and services with user-friendly names. When a user enters a DNS name in an application, DNS services can resolve the name to other information that is associated with the name, such as an IP address.

For example, most users prefer a friendly name, such as corp.contoso.com, to locate a computer, such as a mail server or Web server, on a network. A friendly name can be easier to learn and remember. However, computers communicate over a network by using numeric addresses. To make the use of network resources easier, name systems such as DNS provide a way to map the user-friendly name for a computer or service to its numeric address.

The DNS Server role in Windows Server 2008 combines support for standard DNS protocols with the benefits of integration with Active Directory Domain Services (AD DS) and other Windows networking and security features, including such advanced capabilities as secure dynamic update of DNS resource records.

Server features

The DNS Server role provides the following:

  • A Request for Comments (RFC)-compliant DNS server

    DNS is an open protocol. It is standardized by a set of RFCs. Microsoft supports and complies with these standard specifications.

  • Interoperability with other DNS server implementations

    Because the DNS Server service in Windows Server 2008 is RFC-compliant and it can use standard DNS data file and resource record formats, it can successfully work with most other DNS server implementations, such as those that use the Berkeley Internet Name Domain (BIND) software.

  • Support for Active Directory Domain Services (AD DS)

    DNS is required for support of AD DS to give network computers the ability to locate domain controllers and to support AD DS replication. If you install the AD DS server role on a server, you should install and configure the DNS Server service on the new domain controller at the same time. This ensures the best possible integration and support of AD DS and enhanced DNS server features. You can, however, use another type of DNS server to support AD DS deployment. When you use other types of DNS servers, consider additional issues that are related to DNS interoperability.

  • Enhancements to DNS zone storage in AD DS

    DNS zones can be stored in the domain or application directory partitions of AD DS. An application directory partition is a data structure in AD DS that distinguishes data for different replication purposes. You can specify in which AD DS application directory partition a zone is stored and, consequently, the set of domain controllers between which that zone's data will be replicated. The DNS Server service maintains two application directory partitions, DomainDnsZones and ForestDnsZones, in every domain and forest to store zones for standard replication.

  • Conditional forwarders

    The DNS Server service extends the functionality of standard forwarders by providing conditional forwarders. A conditional forwarder is a DNS server on a network that forwards DNS queries according to the DNS domain name in the query. For example, you can configure a DNS server to forward all the queries it receives for names ending with corp.contoso.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

  • Stub zones

    DNS supports a type of zone called a stub zone. A stub zone is a copy of a zone that contains only those resource records that are necessary to identify the authoritative DNS servers for that zone. A stub zone keeps a DNS server that hosts a parent zone updated with the authoritative DNS servers for its child zone. This helps maintain DNS name resolution efficiency.

  • Enhanced DNS security features

    DNS provides enhanced security administration for the DNS Server service, the DNS Client service, and DNS data.

  • Integration with other Microsoft networking services

    The DNS Server service offers integration with other services and contains features beyond the features that are specified in the RFCs. These features include integration with AD DS, Windows Internet Name Service (WINS), and Dynamic Host Configuration Protocol (DHCP) services.

  • Improved ease of administration

    DNS Manager, the DNS snap-in in Microsoft Management Console (MMC) offers an improved graphical user interface (GUI) for managing the DNS Server service. Also, there are several configuration wizards for performing common server administration tasks. In addition to the DNS snap-in, other tools are provided to help you better manage and support DNS servers and clients on your network.

  • RFC-compliant dynamic update protocol support

    The DNS Server service enables clients to dynamically update resource records, based on the dynamic update protocol (RFC 2136). This improves DNS administration by reducing the time needed to manage these records manually. Computers running the DNS Client service can register their DNS names and IP addresses dynamically.

  • Support for incremental zone transfer between servers

    DNS servers that store DNS data in files use zone transfers to replicate information about a portion of the DNS namespace. When it transfers zones that are not integrated with AD DS, the DNS Server service uses incremental zone transfer to replicate only the changed portions of a zone, which conserves network bandwidth.

  • Single-label host-name resolution without WINS

    The DNS Server service supports a zone called GlobalNames to hold single-label names, that is, names that do not contain the name of a parent domain (such as .com). In networks in which the use of WINS is not an option, the GlobalNames zone provides single-label name resolution for a limited set of centrally administered servers with fixed IP addresses.


Checklist: Add a Domain Controller with the DNS Server Service

Integrating Domain Name System (DNS) with Active Directory Domain Services (AD DS) provides automatic replication between domain controllers in a common domain or forest. By installing multiple domain controllers in a domain running the DNS Server service, you can ensure that DNS will continue to work if a domain controller fails or is taken offline for maintenance. Having multiple domain controllers can also give you the ability to locate the servers in sites where they can be reached most efficiently by DNS clients. In addition, the resulting load balancing can improve overall DNS performance.

Task | Reference
Read about DNS integration with AD DS. | Understanding Active Directory Domain Services Integration
Plan how to divide up your DNS domain name and network address space into forward and reverse lookup zones, as needed. | Planning DNS Zones
Plan your server deployment, including determining how many servers to use and where to put them on your network, keeping in mind that by default domain controllers also operate as DNS servers. | Planning DNS Servers
If clients on your network must be able to resolve external DNS names, consider whether you should configure and use forwarders at DNS servers on your network. | Using Forwarders; Configure a DNS Server to Use Forwarders
Determine how to manage DNS client resolver configurations. | Checklist: Configure DNS Client Settings
Install and configure domain controllers and domains for hosting your zones. | Install a DNS Server; Configure a DNS Server for Use with Active Directory Domain Services
As needed, add delegations in parent zones for any subdomains. For example, if you are adding sub.corp.contoso.com as a new Active Directory domain, you add to it a delegation at the corp.contoso.com zone. | Understanding Zone Delegation; Create a Zone Delegation


Checklist: Store Data in an AD DS Application Partition

You can store Domain Name System (DNS) zones in the domain or application directory partitions of Active Directory Domain Services (AD DS). An application directory partition is a data structure in AD DS that distinguishes data for different replication purposes. When you store a DNS zone in an application directory partition, you can control the zone replication scope by controlling the replication scope of the application directory partition. For a zone to be stored in the specified application directory partition, the DNS server hosting the zone must be enlisted in the specified application directory partition. By default, each AD DS-integrated DNS server maintains enlistments for itself in the appropriate DomainDnsZones and ForestDnsZones application directory partitions.

Task | Reference
Read about AD DS integration. | Understanding Active Directory Domain Services Integration
Read about zone replication. | Understanding DNS Zone Replication in Active Directory Domain Services
Create an application directory partition. | Create a DNS Application Directory Partition
Enlist additional domain controllers in the application directory partition. | Enlist a DNS Server in a DNS Application Directory Partition
Configure the replication scope of the zones to the scope of the application directory partition. | Change the Zone Replication Scope


Checklist: Use Forwarders

By using a forwarder, you can manage name resolution for names that are outside your network, such as names on the Internet or names in other forests or domains.

Task | Reference
Read about forwarders. | Understanding Forwarders
Plan how you will deploy forwarders in your network. | Using Forwarders
Configure the firewall that your network uses to allow only one Domain Name System (DNS) server to communicate with the Internet. |
Configure other servers to use this DNS server as a forwarder. | Configure a DNS Server to Use Forwarders


Checklist: Automatically Remove Stale Resource Records

Aging and scavenging together provide a mechanism for removing stale resource records. These resource records can accumulate in Domain Name System (DNS) zone data over time when computers permanently leave the network. For example, if a computer registers its host (A) resource record at startup and is later disconnected from the network, its host (A) resource record might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

Task | Reference
Read about aging and scavenging. | Understanding Aging and Scavenging
Enable and configure aging and scavenging for the DNS server. | Set Aging and Scavenging Properties for the DNS Server
Enable and configure aging and scavenging for zones | Set Aging and Scavenging Properties for a Zone
Configure aging and scavenging for individual resource records. | Reset Aging and Scavenging Properties for a Specified Resource Record


Checklist: Create an Alias (CNAME) Record

With alias (CNAME) resource records, you can use more than one name to point to a single computer. For example, you can use an alias (CNAME) resource record to allow a server named webserver.contoso.com to also be known as www.contoso.com.

Task | Reference
Read about alias (CNAME) resource records. | Adding Resource Records
Add alias (CNAME) resource records as needed. | Add an Alias (CNAME) Resource Record to a Zone


Checklist: Use Resource Records

In addition to enabling Domain Name System (DNS) clients to locate network resources by name, DNS also provides information about network services and the servers that host those services. This information is contained in resource records that you add to a zone to associate the network service with its host server. For example, to identify the mail server for a domain, you add an MX record to the zone that corresponds to the domain.

Task | Reference
Read about resource records. | Adding Resource Records
Add resource records to a zone as needed. | Add a Resource Record to a Zone


Checklist: Secure Your DNS Server

Especially in the case of Internet-facing Domain Name System (DNS) servers, it is important to ensure that your DNS infrastructure is protected from attack from outside—or even inside—your organization. You can configure your DNS server, when it is integrated with Active Directory Domain Services (AD DS), to use secure dynamic updates to prevent unauthorized modifications to DNS data. You can take additional steps to reduce the chances of an attacker being able to compromise the integrity of your DNS infrastructure.

Task Reference

Determine which DNS security threats are most significant to your environment, and determine the level of security that is required.

Security Information for DNS

To help prevent anyone outside your company from obtaining internal network information, use separate DNS servers for internal and Internet name resolution. Your internal DNS namespace should be hosted on DNS servers behind the firewall for your network. Your external, Internet DNS presence should be managed by a DNS server in a perimeter network. To provide Internet name resolution for internal hosts, you can have your internal DNS servers us a forwarder to send external queries to your external DNS server. Configure your external router and firewall to allow DNS traffic between your internal and external DNS servers only.

Understanding Forwarders;

Using Forwarders

For the DNS servers in your network that are exposed to the Internet, if zone transfer must be enabled, restrict DNS zone transfers to either DNS servers identified in the zone by name server (NS) resource records or to specific DNS servers in your network.

Modify Zone Transfer Settings

If the server running the DNS Server service is a multihomed computer, restrict the DNS Server service to listen only on the interface IP address that is used by its DNS clients and internal servers. For example, a server acting as proxy server may have two network adapters, one for the intranet and one for the Internet. If that server is also running the DNS Server service, you can configure the service to listen for DNS traffic only on the IP address that the intranet network adapter uses.

Configuring Multihomed Servers;

Restrict a DNS server to listen only on selected addresses

Ensure that default server options that secure the caches of all DNS servers against names pollution—have not changed. Names pollution occurs when DNS query responses contain nonauthoritative or malicious data.

Secure the Server Cache Against Names Pollution

Allow only secure dynamic updates for all DNS zones. This ensures that only authenticated users can submit DNS updates using a secure method, which helps prevent the IP addresses of trusted hosts from being hijacked by an attacker.

Understanding Dynamic Update;

Allow Only Secure Dynamic Updates

Disable recursion on DNS servers that do not respond to DNS clients directly and that are not configured with forwarders. A DNS server requires recursion only if it responds to recursive queries from DNS clients or if it is configured with a forwarder. DNS servers use iterative queries to communicate with each other.

Disable Recursion on the DNS Server

If you have a private, internal DNS namespace, configure the root hints on your internal DNS servers to point only to the DNS servers that host your internal root domain and not the DNS servers that host the Internet root domain.

Updating Root Hints;

Update Root Hints on the DNS Server

If the server running the DNS Server service is a domain controller, use Active Directory access control lists (ACLs) to secure access control of the DNS Server service.

Modify Security for the DNS Server Service on a Domain Controller

Use only AD DS-integrated DNS zones. DNS zones that are stored in AD DS can take advantage of Active Directory security features, such as secure dynamic update and the ability to apply AD DS security settings to DNS servers, zones, and resource records.

If a DNS zone is not stored in AD DS, secure the DNS zone file by modifying permissions on the DNS zone file or on the folder where the zone files are stored. The zone file or folder permissions should be configured to allow Full Control only to the System group. By default, zone files are stored in the %systemroot%\System32\Dns folder.

Understanding Active Directory Domain Services Integration;

Configure a DNS Server for Use with Active Directory Domain Services


Checklist: Configure DNS Client Settings

Domain Name System (DNS) client configuration is as important to the proper functioning of your DNS infrastructure as DNS server configuration. Considerations for configuring DNS clients include client-naming conventions (including host name and primary DNS suffix); specifying the DNS servers for a client or allowing Dynamic Host Configuration Protocol (DHCP) to assign DNS servers; and configuring a suffix search list for resolving short, unqualified host names. You can also configure connection-specific DNS settings for computers with multiple network adapters or Remote Access Service (RAS) connections.

Task | Reference
Read about client configuration. | Understanding DNS Client Settings
Configure static DNS clients. | Configure DNS for Static Clients
Configure DHCP servers and DHCP-enabled clients. | Enable DNS for DHCP-Enabled Clients


Checklist: Migrate a DNS Server

You can migrate a DNS server by upgrading a DNS server running an earlier version of Windows to Windows Server 2008, moving zone files from an existing DNS server running another DNS server implementation, or migrating zones using master-secondary zone transfer to DNS servers running Windows Server 2008. Migrating a Domain Name System (DNS) server can improve the performance, security, and reliability of your DNS infrastructure by giving you access to the advanced features that are available in Windows Server 2008.

  • Upgrading a DNS server

  • Moving zone files

  • Migrating zones from BIND servers

  • Migrating zones from Windows-based DNS servers

Upgrading a DNS server

Task | Reference
Any zones or server configuration files and parameters that are created and stored using the Windows Server 2003 version of the DNS Server service are stored in the same system folder locations. There is no conversion of data required during the process of upgrading from Windows Server 2003 to Windows Server 2008. |

Moving zone files

Task Reference

Copy any zone or boot files that were created with Berkeley Internet Name Domain (BIND) that you intend to use with the DNS Server service to the %systemroot%\System32\DNS folder on the server running Windows Server 2008.

If you continue to use a BIND boot file to provide the initial configuration settings that are used by the DNS Server service when it is started, change the boot method that is used by the DNS Server service. Or, rename the zone files from the BIND naming convention to the convention that is used by DNS servers running under the DNS Server service that is provided in Windows operating systems.

Change the Boot Method Used by the DNS Server

If you do not migrate the BIND boot file or specify the BIND name when you create the zones using DNS Manager, you will have to rename these zones:

  • Boot file: Rename named.boot to Boot

  • Forward lookup zone file: Rename db.domain_name to domain_name.dns

  • Reverse lookup zone file: db.IP_network_forward_notation to IP_network_reverse_notation.dns

For a reverse lookup zone, BIND uses a convention of noting reverse domain names as a forward notation of the mapped IP network, such as db.192.1.168 for a reverse lookup zone that is created for an example IP network address of 192.168.1.0. DNS servers running Windows Server 2008, however, use the fully qualified domain name (FQDN) for the zone, which includes the in-addr.arpa domain, to complete the file name. In this example, the correct name to use for the same zone in Windows Server 2008 DNS is 168.1.192.in-addr.arpa.dns when you copy and rename the file.

Additional considerations

  • If you are using the BIND boot file with the DNS Server service after migration, there are other limitations that apply to the use of this file by the DNS Server service. For example, some BIND boot directives are not supported—in particular, xfrnets and other directives that are provided with versions of BIND, such as version 8.1.1 or later. For more information, see articles Q194513 and Q234144 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=4441).

  • If you are accustomed to manually editing DNS zone files, be aware that the DNS Server service uses Request for Comments (RFC)-compliant notation for its supported resource records. In most cases, the DNS Server service interprets and loads resource records from zone files that were originally created for BIND-based DNS servers, without any need for file changes. If, however, you have used nonstandard record formatting, the DNS Server service can detect these edits and interpret them as bad zone data.

Migrating zones from BIND servers

Task | Reference
Configure the BIND servers as the master servers for each of the zones that you want to migrate. |
On the server running the DNS Server service, add secondary zones for all of your existing zones that are hosted at the BIND-based DNS servers. | Add a Forward Lookup Zone
If necessary, create reverse lookup zones for all of your existing reverse lookup zones that are hosted at the BIND-based DNS servers. | Add a Reverse Lookup Zone
After completing the zone transfers, convert any of the secondary zones to primary zones for the zones that were obtained from primary zones at the BIND servers. | Change the Zone Type
Optional: If the DNS server running Windows Server 2008 is a domain controller, store the zone in Active Directory Domain Services (AD DS). | Change the Zone Type
Configure the previous primary servers to be secondary servers for the migrated zones, or demote the previous primary servers. |
For the other secondary zones that remain, update the master servers for those zones to use the new primary DNS servers running Windows Server 2008. |

Migrating zones from Windows-based DNS servers

These tasks are necessary only if the zones that you are migrating are hosted on Windows-based servers and not stored in AD DS.

Task | Reference
On the server running Windows Server 2008, create secondary zones for all of your existing zones that are hosted at the Windows-based DNS servers. | Add a Forward Lookup Zone
If necessary, create reverse lookup zones for all of your existing reverse lookup zones that are hosted at the Windows-based DNS servers. | Add a Reverse Lookup Zone
After you complete the zone transfers, convert the secondary zones to primary zones for the zones that were migrated. | Change the Zone Type
Optional: If the DNS server running Windows Server 2008 is a domain controller, store the zone in AD DS. | Change the Zone Type
Optional: To continue using the previous master servers as DNS servers, convert the migrated zones on the previous master servers to secondary zones. | Change the Zone Type


Checklist: Create a Reverse Lookup Zone

Domain Name System (DNS) servers can enable clients to determine the DNS name of a host based on the host's IP address by providing a special zone called a reverse lookup zone. A reverse lookup zone contains pointer (PTR) resource records that map IP addresses to the host name. Some applications, such as secure Web applications, rely on reverse lookups. Create a reverse lookup zone only if applications running on your network require it. Otherwise, disable dynamic updates for pointer (PTR) resource records by client computers.

Task | Reference
Read about reverse lookups. | Understanding Reverse Lookup
Create a reverse lookup zone. | Add a Reverse Lookup Zone


Installing and Configuring Servers

The first step in implementing Domain Name System (DNS) in a network is installing and configuring the servers that will provide the service. Before you do so, however, it is important to plan the deployment to ensure the greatest effectiveness of your DNS infrastructure. In addition to planning your zone layout and server location and function, also take into consideration whether you will integrate your DNS infrastructure with Active Directory Domain Services (AD DS).

  • Understanding Active Directory Domain Services Integration

  • Understanding Forwarders

  • Using Forwarders

  • Planning DNS Zones

  • Planning DNS Servers

  • Understanding DNS Zone Replication in Active Directory Domain Services

  • Install a DNS Server

  • Configure a DNS Server for Use with Active Directory Domain Services

  • Configure a New DNS Server

  • Configure a DNS Server to Use Forwarders

  • Create a DNS Application Directory Partition

  • Enlist a DNS Server in a DNS Application Directory Partition

  • Remove a DNS Server from a DNS Application Directory Partition

  • Change the Boot Method Used by the DNS Server

  • Configuring Multihomed Servers

  • Restrict a DNS server to listen only on selected addresses

  • Secure the Server Cache Against Names Pollution

  • Modify Security for the DNS Server Service on a Domain Controller

  • Disable Recursion on the DNS Server

  • Updating Root Hints

  • Update Root Hints on the DNS Server


Understanding Active Directory Domain Services Integration

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

When you deploy Domain Name System (DNS) servers with AD DS, consider the following:

  • DNS is required for locating domain controllers.

    The Net Logon service uses DNS server support to provide registration of domain controllers in your DNS domain namespace.

  • DNS servers running Windows Server 2003 or Windows Server 2008 can use AD DS for storing and replicating your zones.

    By integrating your zones with AD DS, you can take advantage of DNS features, such as AD DS replication, secure dynamic updates, and record aging and scavenging.

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. As part of this process, you are prompted to specify a DNS domain name for the AD DS domain which you are joining and for which you are promoting the server, and you are offered the option to install the DNS Server role. This option is provided because a DNS server is required to locate this server or other domain controllers for members of an AD DS domain.

Benefits of AD DS integration

For networks that deploy DNS to support AD DS, directory-integrated primary zones are strongly recommended. They provide the following benefits:

  • DNS features multimaster data replication and enhanced security based on the capabilities of AD DS.

    In a standard zone storage model, DNS updates are conducted based on a single-master update model. In this model, a single authoritative DNS server for a zone is designated as the primary source for the zone. This server maintains the master copy of the zone in a local file. With this model, the primary server for the zone represents a single fixed point of failure. If this server is not available, update requests from DNS clients are not processed for the zone.

    With directory-integrated storage, dynamic updates to DNS are sent to any AD DS-integrated DNS server and are replicated to all other AD DS-integrated DNS servers by means of AD DS replication. In this model, any AD DS-integrated DNS servercan accept dynamic updates for the zone. Because the master copy of the zone is maintained in the AD DS database, which is fully replicated to all domain controllers, the zone can be updated by the DNS servers operating at any domain controller for the domain. With the multimaster update model of AD DS, any of the primary servers for the directory-integrated zone can process requests from DNS clients to update the zone as long as a domain controller is available and reachable on the network.

    Also, when you use directory-integrated zones, you can use access control list (ACL) editing to secure a dnsZone object container in the directory tree. This feature provides detailed access to either the zone or a specified resource record in the zone. For example, an ACL for a zone resource record can be restricted so that dynamic updates are allowed only for a specified client computer or a secure group, such as a domain administrators group. This security feature is not available with standard primary zones.

  • Zones are replicated and synchronized to new domain controllers automatically whenever a new one is added to an AD DS domain.

    Although the DNS Server service can be selectively removed from a domain controller, directory-integrated zones are already stored at each domain controller. Therefore, zone storage and management is not an additional resource. Also, the methods that are used to synchronize directory-stored information offer performance improvement over standard zone update methods, which can potentially require transfer of the entire zone.

  • By integrating storage of your DNS zone databases in AD DS, you can streamline database replication planning for your network.

    When your DNS namespace and AD DS domains are stored and replicated separately, you must plan and potentially administer each of these items separately. For example, when you use standard DNS zone storage and AD DS together, you have to design, implement, test, and maintain two different database replication topologies.

    For example, one replication topology is needed for replicating directory data between domain controllers, and another topology is needed for replicating zone databases between DNS servers. This can create additional administrative complexity for planning and designing your network and allowing for its eventual growth. By integrating DNS storage, you unify storage management and replication issues for both DNS and AD DS, merging and viewing them together as a single administrative entity.

  • Directory-integrated replication is faster and more efficient than standard DNS replication.

    Because AD DS replication processing is performed on a per-property basis, only relevant changes are propagated. Less data is used and submitted in updates for directory-stored zones.

Only primary zones can be stored in the directory. A DNS server cannot store secondary zones in the directory. It must store them in standard text files. The multimaster replication model of AD DS removes the need for secondary zones when all zones are stored in AD DS.

For more information about configuring DNS for AD DS integration, see Configure a DNS Server for Use with Active Directory Domain Services and Checklist: Add a Domain Controller with the DNS Server Service.


Understanding Forwarders

A forwarder is a Domain Name System (DNS) server on a network that forwards DNS queries for external DNS names to DNS servers outside that network. You can also forward queries according to specific domain names using conditional forwarders.

You designate a DNS server on a network as a forwarder by configuring the other DNS servers in the network to forward the queries that they cannot resolve locally to that DNS server. By using a forwarder, you can manage name resolution for names outside your network, such as names on the Internet, and improve the efficiency of name resolution for the computers in your network. For more information about forwarders and conditional forwarders, see Using Forwarders.

The following figure illustrates how external name queries are directed with forwarders.

Example of a common forwarder configuration

When you designate a DNS server as a forwarder, you make that forwarder responsible for handling external traffic, which limits DNS server exposure to the Internet. A forwarder builds up a large cache of external DNS information because all the external DNS queries in the network are resolved through it. In a small amount of time, a forwarder resolves a large number of external DNS queries using this cached data. This decreases the Internet traffic over the network and the response time for DNS clients.

A DNS server that is configured to use a forwarder behaves differently than a DNS server that is not configured to use a forwarder. A DNS server that is configured to use a forwarder behaves as follows:

  1. When the DNS server receives a query, it attempts to resolve this query by using the zones that it hosts and by using its cache.

  2. If the query cannot be resolved using local data, the DNS server forwards the query to the DNS server that is designated as a forwarder.

  3. If forwarders are unavailable, the DNS server attempts to use its root hints to resolve the query..

When a DNS server forwards a query to a forwarder, it sends a recursive query to the forwarder. This is different than the iterative query that a DNS server sends to another DNS server during standard name resolution (name resolution that does not involve a forwarder).

Conditional forwarders

A conditional forwarder is a DNS server on a network that forwards DNS queries according to the DNS domain name in the query. For example, you can configure a DNS server to forward all the queries that it receives for names ending with corp.contoso.com to the IP address of a specific DNS server or to the IP addresses of multiple DNS servers.

Internet name resolution

DNS servers can use conditional forwarders to resolve queries between the DNS domain names of companies that share information. For example, two companies, Wingtip Toys and Tailspin Toys, want to improve how the DNS clients of Wingtip Toys resolve the names of the DNS clients of Tailspin Toys. The administrators from Tailspin Toys inform the administrators of Wingtip Toys about the set of DNS servers in the Tailspin Toys network where Wingtip Toys can send queries for the domain dolls.tailspintoys.com. The DNS servers in the Wingtip Toys network are configured to forward all queries for names ending with dolls.tailspintoys.com to the designated DNS servers in the network for Tailspin Toys. Consequently, the DNS servers in the Wingtip Toys network do not have to query their internal root servers—or the Internet root servers—to resolve queries for names ending with dolls.tailspintoys.com.


Using Forwarders

To use forwarders to manage the Domain Name System (DNS) traffic between your network and the Internet, configure your network's firewall to allow only one DNS server to communicate with the Internet. When you configure the other DNS servers in your network to forward queries that they cannot resolve locally to that DNS server, it acts as your forwarder. For more information about forwarders, see Understanding Forwarders.

Forwarding sequence

The order of the IP addresses that are listed as forwarders on a DNS server determines the sequence in which the IP addresses are used. After the DNS server forwards the query to the forwarder with the first IP address, it waits a short period of time for an answer from that forwarder (according to the DNS server's forwarding time-out setting) before resuming the forwarding operation with the next IP address. It continues this process until it receives an affirmative answer from a forwarder.

For example, in the following illustration the DNS servers with the first and second forwarder IP addresses do not respond to the DNS server. The DNS server with the third forwarder IP address responds, and the query is forwarded to that DNS server.

Outsourced VPN remote access

Unlike conventional resolution, where a roundtrip time (RTT) is associated with each server, the IP addresses in the forwarders list are not ordered according to roundtrip time. You must reorder them manually to change the preference.

Conditional forwarders

Conditional forwarders are DNS servers that forward queries according to domain names. Rather than having a DNS server forward all queries it cannot resolve locally to a forwarder, you can configure DNS servers to forward queries to different forwarders according to the specific domain names that are contained in the queries. Forwarding according to domain names improves conventional forwarding by adding a name-based condition to the forwarding process.

The conditional forwarder setting for a DNS server consists of the following:

  • The domain names for which the DNS server will forward queries

  • One or more DNS server IP addresses for each domain name that is specified

When a DNS client or server performs a query operation against a DNS server, the DNS server checks to determine if the query can be resolved with its own zone data or the data stored in its cache. If the DNS server is configured to forward for the domain name that is designated in the query, the query is forwarded to the IP address of a forwarder that is associated with that domain name. For example, in the following illustration, each of the queries for the domain names is forwarded to a DNS server that is associated with the domain name.

Dial-up and VPN remote access

If the DNS server has no forwarder listed for the name that is designated in the query, it attempts to resolve the query using standard recursion. For more information, see Configure a DNS Server to Use Forwarders.

You can use conditional forwarders to improve name resolution between internal (private) DNS namespaces that are not part of the DNS namespace of the Internet. Such DNS namespaces may be a result of a company merger. When you configure the DNS servers in one internal namespace to forward all queries to the authoritative DNS servers in a second internal namespace, conditional forwarders enable name resolution between the two namespaces without performing recursion on the DNS namespace of the Internet. This enhancement to name resolution also avoids your DNS servers performing recursion to your internal root for different namespaces within your network.

Important

A DNS server cannot forward queries for the domain names in the zones that it hosts. For example, the authoritative DNS server for the zone widgets.tailspintoys.com cannot forward queries according to the domain name widgets.tailspintoys.com. The DNS server that is authoritative for widgets.tailspintoys.com can forward queries for DNS names that end with hr.widgets.tailspintoys.com, if hr.widgets.tailspintoys.com is delegated to another DNS server.

Conditional forwarder domain name length

When a DNS server that is configured with a conditional forwarder receives a query for a domain name, it compares that domain name with its list of domain name conditions and uses the longest domain name condition that corresponds to the domain name in the query. For example, in the next illustration, the DNS server performs the following conditional forwarding logic to determine how a query for a domain name will be forwarded:

  1. The DNS server receives a query for toys.widgets.tailspintoys.com.

  2. It compares that domain name with both tailspintoys.com and widgets.tailspintoys.com.

  3. The DNS server determines that widgets.tailspintoys.com is the domain name that more closely matches the domain name query.

  4. The DNS server forwards the query to the DNS server with the IP address 172.31.255.255, which is associated with widgets.tailspintoys.com.

Ethernet switch access


Planning DNS Zones

When you first partition your namespace into zones, review the traffic patterns in your current or proposed network. Although Domain Name System (DNS) is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients that should be reviewed. This is particularly true in cases where DNS is used on routed networks. To review DNS traffic, you can use DNS server statistics or the DNS performance counters that are provided with System Monitor.

In addition to traffic routing, consider the impact of the following common types of DNS-related communication, especially when you are operating across slow-speed links on a wide area network (WAN):

  • Server-to-server traffic that is caused both by zone transfers with other DNS servers and by DNS interoperability with other servers (for example, when Windows Internet Name Service (WINS) lookup is enabled)

  • Client-to-server traffic that is caused by both query loads and dynamic updates that are sent by DNS client computers or DHCP servers providing dynamic updating for earlier-version DNS clients that do not support dynamic updates

For small, flat namespaces, you might use full replication of all DNS zones to all DNS servers in your network. For large, vertical namespaces, this is neither possible nor recommended. In larger networks, it is often necessary to study, test, analyze, and revise your zone plans based on observed or estimated traffic patterns. After careful analysis, you can partition and delegate your DNS zones based on the requirements for providing efficient and fault-tolerant name service to each location or site.

The DNS Server service supports incremental zone transfers between servers that replicate a standard zone. This feature can reduce DNS replication traffic considerations, and you should review it in zone planning.

You might also want to explore the use of caching-only servers, which do not host DNS zones. Caching-only servers are a good option at small remote sites that have a stable and minimal use for DNS name service but are located across a WAN where the transfer of a large zone over a slower link can consume large amounts of resources.


Planning DNS Servers

When you plan your Domain Name System (DNS) servers, it is important to do the following:

  • Perform capacity planning, and review server hardware requirements.

  • Determine how many DNS servers you need and their role in your network.

    When you consider the number of DNS servers to use, decide which servers will host primary and secondary copies of zones. Also, if you are using Active Directory Domain Services (AD DS), determine whether the server computer will perform as a domain controller or as a member server in the domain.

  • Decide where you are going to place DNS servers on your network for traffic loads, replication, and fault tolerance.

  • Decide if you are using only DNS servers running Windows Server 2008 for all your DNS servers or if you are operating a mixture of DNS server implementations.

Server capacity planning

Planning and deploying DNS servers on your network involves examining several aspects of your network and the capacity requirements for any DNS servers that you intend to use in it. Some questions to consider when you are planning DNS server capacity include the following:

  • How many zones is the DNS server expected to load and host?

  • For each zone that the server is loading for service, how large is the zone (based on the size of the zone file or the number of resource records used in the zone)?

  • For a multihomed DNS server, how many interfaces are to be enabled for listening to and servicing DNS clients on each of the server's connected subnets?

  • How many total or overall DNS query requests from all of its clients is a DNS server expected to receive and service?

In many cases, adding more RAM to a DNS server can provide the most noticeable improvements in performance. This is because the DNS Server service fully loads all of its configured zones into memory at startup. If your server is operating and loading a large number of zones and dynamic updates occur frequently for zone clients, additional memory can be helpful.

Keep in mind that, for typical usage, the DNS server consumes system memory as follows:

  • Approximately 4 megabytes (MB) of RAM is used when the DNS server is started without any zones.

  • For each addition of zones or resource records to the server, the DNS server consumes additional server memory.

  • It is estimated that for the addition of every resource record to a server zone, an average of approximately 100 bytes of server memory is used.

    For example, if a zone containing 1000 resource records is added to a server, it requires approximately 100 kilobytes (KB) of server memory.

When you determine your DNS server plans, you can start by reviewing sample DNS server performance test results that are collected by your DNS development and testing teams. In addition, you can use DNS server-related counters that are provided with monitoring tools to obtain your own performance measurements.

Important

The previous recommendations are not intended to indicate maximum performance or limitations for DNS servers. These numbers are approximate, and they can be influenced by the type of resource records entered in zones, the number of resource records with the same owner name, and the number of zones in use at a specific DNS server.

Where to place DNS servers

Most often, you will install DNS servers on all domain controllers. If, however, you have reason not to deploy DNS servers on every domain controller, you can follow these guidelines to choose where to place your DNS servers.

In general, place your DNS servers at a location on your network that is centrally accessible to your clients. It is often most practical to use a DNS server on each subnet. There are several questions to consider when you are deciding where a DNS server is needed:

  • If you are deploying DNS to support AD DS, is the DNS server computer also a domain controller or is it likely to become a domain controller in the future?

  • If the DNS server stops responding, are its local clients able to gain access to an alternate DNS server?

  • If the DNS server is located on a subnet that is remote to some of its clients, what other DNS servers or name resolution options are available if the routed connection stops responding?

For example, if you have a routed local area network and high-speed links that are fairly reliable, you may be able to use one DNS server for a larger, multiple subnetted network area. If you have a high number of client nodes on a single subnet design, you may want to add more than one DNS server to the subnet to provide backup and failover if the preferred DNS server stops responding.

When you are determining the number of DNS servers that you need, assess the effect of zone transfers and DNS query traffic on slower links in your network. Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients that should be reviewed, particularly when the DNS servers are in local area network (LAN) or wide area network (WAN) environments with complex routing.

Consider the effects of zone transfer over slower speed links, such as those that are typically used for a WAN connection. Although the DNS Server service supports incremental zone transfers and DNS clients and servers can cache recently used names, traffic considerations are sometimes still an issue, particularly when Dynamic Host Configuration Protocol (DHCP) leases are shortened and, as a result, dynamic updates in DNS are performed more frequently. One option for dealing with remote locations on WAN links is to set up a DNS server at these locations to provide caching-only DNS service.

With most installations, you should have at least two server computers hosting each of your DNS zones, for fault tolerance. When you are making any final determinations about the number of servers to use, first assess the level of fault tolerance that is appropriate for your network.

When only a single DNS server is used on a small LAN in a single-subnet environment, you can configure the single server to simulate both the primary and secondary servers for a zone.


Understanding DNS Zone Replication in Active Directory Domain Services

You can store Domain Name System (DNS) zones in the domain or application directory partitions of Active Directory Domain Services (AD DS). A partition is a data structure in AD DS that distinguishes data for different replication purposes. For more information, see Understanding Active Directory Domain Services Integration.

The following table describes the available zone replication scopes for AD DS-integrated DNS zone data.

Zone replication scope | Description
All DNS servers in the forest that are domain controllers running Windows Server 2003 or Windows Server 2008 | Replicates zone data to all Windows Server 2003 and Windows Server 2008 domain controllers running the DNS Server service in the AD DS forest. This option replicates zone data to the ForestDNSZones partition. Therefore, it provides the broadest replication scope.
All DNS servers in the domain that are domain controllers running Windows Server 2003 or Windows Server 2008 | Replicates zone data to all Windows Server 2003 and Windows Server 2008 domain controllers running the DNS Server service in the Active Directory domain. This option replicates zone data to the DomainDNSZone partition. It is the default setting for DNS zone replication in Windows Server 2003 and Windows Server 2008.
All domain controllers in the Active Directory domain | Replicates zone data to all domain controllers in the Active Directory domain. If you want Windows 2000 DNS servers to load an Active Directory–integrated zone, you must specify this scope for that zone.
All domain controllers in a specified application directory partition | Replicates zone data according to the replication scope of the specified application directory partition. For a zone to be stored in the specified application directory partition, the DNS server hosting the zone must be enlisted in the specified application directory partition. Use this scope when you want zone data to be replicated to domain controllers in multiple domains but you do not want the data to replicate to the entire forest. For more information, see Create a DNS Application Directory Partition and Enlist a DNS Server in a DNS Application Directory Partition.

When you decide which replication scope to choose, consider that the broader the replication scope, the greater the network traffic caused by replication. For example, if you decide to have AD DS–integrated DNS zone data replicated to all DNS servers in the forest, this will produce greater network traffic than replicating the DNS zone data to all DNS servers in a single AD DS domain in that forest.

AD DS-integrated DNS zone data that is stored in an application directory partition is not replicated to the global catalog for the forest. The domain controller that contains the global catalog can also host application directory partitions, but it will not replicate this data to its global catalog.

AD DS-integrated DNS zone data that is stored in a domain partition is replicated to all domain controllers in its AD DS domain, and a portion of this data is stored in the global catalog. This setting is used to support Windows 2000.

If an application directory partition's replication scope replicates across AD DS sites, replication will occur with the same intersite replication schedule as is used for domain partition data.

By default, the Net Logon service registers domain controller locator (Locator) DNS resource records for the application directory partitions that are hosted on a domain controller in the same manner as it registers domain controller locator (Locator) DNS resource records for the domain partition that is hosted on a domain controller.


Install a DNS Server

Installing a Domain Name System (DNS) server involves adding the DNS server role to an existing Windows Server 2008 server. You can also install the DNS server role when you install the Active Directory Domain Services (AD DS) role. This is the preferred method for installing the DNS Server role if you want to integrate your DNS domain namespace with the AD DS domain namespace.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To install a DNS server

  1. Open Server Manager. To open Server Manager, click Start, and then click Server Manager.

  2. In the results pane, under Roles Summary, click Add roles.

  3. In the Add Roles Wizard, if the Before You Begin page appears, click Next.

  4. In the Roles list, click DNS Server, and then click Next.

  5. Read the information on the DNS Server page, and then click Next.

  6. On the Confirm Installation Options page, verify that the DNS Server role will be installed, and then click Install.

Additional considerations

  • We recommend that you configure the computer to use a static IP address. If the DNS server is configured to use DHCP-assigned dynamic addresses, when the DHCP server assigns a new IP address to the DNS server, the DNS clients that are configured to use that DNS server's previous IP address will not be able to resolve the previous IP address and locate the DNS server.

  • After you install a DNS server, you can decide how to administer it and its zones. Although you can use a text editor to make changes to server boot and zone files, this method is not recommended. DNS Manager and the DNS command-line tool, dnscmd, simplify maintenance of these files, and they should be used whenever possible. After you begin using DNS Manager or command-line management of these files, editing them manually is not recommended.

  • You can administer DNS zones that are integrated with AD DS only with DNS Manager or the dnscmd command-line tool. You cannot administer these zones with a text editor.

  • If you uninstall a DNS server that hosts AD DS-integrated zones, these zones are saved or deleted according to their storage type. For all storage types, the zone data is stored on other domain controllers or DNS servers. The zone data is not deleted unless the DNS server that you uninstall is the last DNS server hosting that zone.

  • If you uninstall a DNS server that hosts standard DNS zones, the zone files remain in the %systemroot%\system32\Dns directory, but they are not reloaded if the DNS server is reinstalled. If you create a new zone with the same name as an old zone, the old zone file is replaced with the new zone file.

  • When they write DNS server boot and zone data to text files, DNS servers use the Berkeley Internet Name Domain (BIND) file format that is recognized by legacy BIND 4 servers, not the more recent BIND 8 format.

Additional references

  • Configure a DNS Server for Use with Active Directory Domain Services

  • Configure a New DNS Server


Configure a DNS Server for Use with Active Directory Domain Services

When you install Active Directory Domain Services (AD DS) with the Active Directory Domain Services Installation Wizard, the wizard gives you the option to automatically install and configure a DNS server. The resulting DNS zone is integrated with the AD DS domain that is controlled by the AD DS server.

To install AD DS on this computer, use Server Manager.

  • This method applies only to server computers that are used as domain controllers. If member servers (server that are not used as domain controllers) are used as DNS servers, they are not integrated with AD DS.

  • If you choose the wizard option to automatically install and configure a local DNS server, the DNS server is installed on the computer where you are running the wizard and the computer's preferred DNS server setting is configured to use the new local DNS server. Configure any other computers that will join this domain to use this DNS server's IP address as their preferred DNS server.

Additional references

  • Checklist: Add a Domain Controller with the DNS Server Service

  • Understanding Active Directory Domain Services Integration


Configure a New DNS Server

When a new Domain Name System (DNS) server is not installed on a domain controller, you typically perform the following tasks to configure it:

  • Create a forward and (optional) reverse lookup zone.

  • Determine whether the server will allow dynamic updates, including whether nonsecure updates are allowed.

  • Determine whether queries will be forwarded and to what servers.

Instead of configuring these settings, you can choose instead to configure the server to use root hints so that you can perform these configuration tasks at a later time.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Configuring a new DNS server

  • Using the Windows interface

  • Using a command line
To configure a new DNS server using the Windows interface

  1. Open DNS Manager.

  2. If necessary, add the applicable server to the snap-in, and then connect to it.

  3. In the console tree, click the applicable DNS server.

    Where?

    • DNS/DNS server

  4. On the Action menu, click Configure a DNS Server.

  5. Follow the instructions in the Configure a DNS Server Wizard.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • If the DNS server is running locally, you do not have to perform step 2.

  • When you finish configuring the server, you may have to complete additional tasks, such as enabling dynamic updates for its zones or adding resource records to its zones.

To configure a new DNS server using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config {<ZoneName>|..AllZones} <Property> {1|0}

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Specifies that the command configures the specified zone.
{<ZoneName>|..AllZones} | Specifies the name of the zone to be configured. To apply the configuration for all zones hosted by the specified DNS server, type ..AllZones.
<Property> | Specifies the server property or zone property to be configured. There are different properties available for servers and zones. For a list of the available properties, at the command prompt, type: dnscmd /Config /help.
{1|0} | Sets configuration options to either 1 (on) or 0 (off). Note that some server and zone properties must be reset as part of a more complex operation.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • When you finish configuring the server, you may have to complete additional tasks, such as enabling dynamic updates for its zones or adding resource records to its zones.

Additional references

  • Installing and Configuring Servers

  • Install a DNS Server


Configure a DNS Server to Use Forwarders

A forwarder is a Domain Name System (DNS) server on a network that is used to forward DNS queries for external DNS names to DNS servers outside that network. You can also configure your server to forward queries according to specific domain names using conditional forwarders.

A DNS server on a network is designated as a forwarder when the other DNS servers in the network are configured to forward the queries that they cannot resolve locally to that DNS server. By using a forwarder, you can manage name resolution for names outside your network, such as names on the Internet, which can improve the efficiency of name resolution for the computers in your network. For more information about forwarders and conditional forwarders, see Understanding Forwarders.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Configuring a DNS server to use forwarders

  • Using the Windows interface

  • Using a command line
To configure a DNS server to use forwarders using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS/Applicable DNS server

  3. On the Action menu, click Properties.

  4. On the Forwarders tab, under DNS domain, click a domain name.

  5. Under Selected domain's forwarder IP address list, type the IP address of a forwarder, and then click Add.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • To create a new domain name, click New, and then, under DNS domain, type the domain name.

  • When you specify a conditional forwarder, select a DNS domain name before you enter an IP address.

  • By default, the DNS server waits five seconds for a response from one forwarder IP address before it tries another forwarder IP address. In Number of seconds before forward queries time out, you can change the number of seconds that the DNS server waits. When the server has exhausted all forwarders, it attempts standard recursion.

  • If you want the DNS server to only use forwarders and not attempt any further recursion if the forwarders fail, select the Do not use recursion for this domain check box.

    You can disable recursion for the DNS server so that it will not perform recursion on any query. If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

  • Do not enter a forwarder's IP address more than once in a DNS server's forwarders list because it is a more reliable or geographically closer server. If you prefer one of the forwarders, put that forwarder first in the series of forwarder IP addresses.

  • You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary zone, secondary zone, or stub zone for that domain name. For example, if a DNS server is authoritative for the domain name corp.contoso.com (that is, it hosts the primary zone for that domain name), you cannot configure that DNS server with a conditional forwarder for corp.contoso.com.

  • You can prevent common problems that are associated with forwarders by configuring your DNS servers to avoid overusing your forwarders.

To configure a DNS server to use forwarders using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ResetForwarders <MasterIPaddress ...> [/TimeOut <Time>] [/Slave]

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ResetForwarders | Required. Configures a forwarder.
<MasterIPaddress...> | Required. Specifies a space-separated list of one or more IP addresses of the DNS servers where queries are forwarded. You may specify a list of space-separated IP addresses.
/TimeOut | Specifies the timeout setting. The timeout setting is the number of seconds before unsuccessful forward queries time out.
<Time> | Specifies the value for the /TimeOut parameter. The value is in seconds. The default timeout is five seconds.
/Slave | Determines whether or not the DNS server uses recursion when it queries for the domain name that is specified by ZoneName.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ResetForwarders /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • To set the conditional forwarder for a zone, use the following command:

    dnscmd <ServerName> /ZoneAdd <ZoneName> /Forwarder <MasterIPaddress ...> [/TimeOut <Time>] [/Slave]
    The /ZoneAdd command adds the zone specified by the ZoneName parameter. The parameter IPAddress is the IP address where the DNS server will forward unsolvable DNS queries. The /Slave parameter sets the DNS server as a subordinate server. The /NoSlave parameter (default setting) sets the DNS server as a nonsubordinate server, which means that it will perform recursion. The /Timeout and Time parameters are described in the previous table.

  • To view a zone that is added only as a conditional forwarder, use the following command:

    dnscmd <ServerName> /ZoneInfo <ZoneName>
  • To reset the forwarder IP addresses for a conditional forwarder domain name, use the following command:

    dnscmd <ServerName> /ZoneResetMasters <ZoneName> [/Local] [<ServerIPs>]
    The /Local parameter sets the local master list for Active Directory–integrated forwarders. The ServerIPs parameter is the list of one or more IP addresses of master servers for the zone. Master servers may include DNS servers that host primary or secondary copies of the zone, but they should not include DNS server IP addresses in such a way that two DNS servers that host copies of a zone use each other as master servers. Such a configuration makes the forwarding path cyclical.

  • You cannot use a domain name in a conditional forwarder if the DNS server hosts a primary zone, secondary zone, or stub zone for that domain name. For example, if a DNS server is authoritative for the domain name corp.contoso.com (that is, it hosts the primary zone for that domain name), you cannot configure that DNS server with a conditional forwarder for corp.contoso.com.

  • You can prevent common problems that are associated with forwarders by configuring your DNS servers to avoid overusing your forwarders.

Additional references

  • Using Forwarders


Create a DNS Application Directory Partition

You can store Domain Name System (DNS) zones in the domain or application directory partitions of Active Directory Domain Services (AD DS). A partition is a data structure in AD DS that distinguishes data for different replication purposes. When you create an application directory partition for DNS, you can control the scope of replication for the zone that is stored in that partition. For more information, see Understanding Active Directory Domain Services Integration.

Membership in the Enterprise Admins group is required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To create a DNS application directory partition

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /CreateDirectoryPartition <FQDN>

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/CreateDirectoryPartition | Required. Creates a DNS application directory partition.
<FQDN> | Required. Specifies the name of the new DNS application directory partition. You must use a DNS fully qualified domain name (FQDN).

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /CreateDirectoryPartition /?

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Checklist: Store Data in an AD DS Application Partition

  • Understanding DNS Zone Replication in Active Directory Domain Services

  • Enlist a DNS Server in a DNS Application Directory Partition


Enlist a DNS Server in a DNS Application Directory Partition

After you create a Domain Name System (DNS) application directory partition to store a zone, you must enlist the DNS server that hosts the zone in the application directory partition. For more information, see Understanding DNS Zone Replication in Active Directory Domain Services.

Membership in DnsAdmins or Domain Admins, or the equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enlist a DNS server in a DNS application directory partition

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /EnlistDirectoryPartition <FQDN>

Value | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/EnlistDirectoryPartition | Required. Enlists a DNS server in a DNS application directory partition.
<FQDN> | Required. Specifies the fully qualified domain name (FQDN) of the DNS application directory partition.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /EnlistDirectoryPartition /?

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Checklist: Store Data in an AD DS Application Partition


Remove a DNS Server from a DNS Application Directory Partition

You can perform this procedure when you no longer want the Domain Name System (DNS) server to participate in replication of the zone that is hosted in a DNS application directory partition. You cannot remove a DNS server from the DomainDnsZones or ForestDnsZones application directory partitions.

To perform this procedure, you must be a member of the DnsAdmins or the Domain Admins group in Active Directory Domain Services (AD DS), or you must have been delegated the appropriate authority. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To remove a DNS server from a DNS application directory partition

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /UnenlistDirectoryPartition <FQDN>

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/UnenlistDirectoryPartition | Required. Removes a DNS server from a DNS application directory partition.
<FQDN> | Required. Specifies the fully qualified domain name (FQDN) of the DNS application directory partition from which you are removing the DNS server that is specified by ServerName.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /UnenlistDirectoryPartition /?

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Active Directory Domain Services Integration

  • Create a DNS Application Directory Partition

  • Enlist a DNS Server in a DNS Application Directory Partition


Change the Boot Method Used by the DNS Server

You can use this procedure to control whether the Domain Name System (DNS) server obtains its startup information from the registry, from a boot file, or from Active Directory Domain Services (AD DS).

By default, DNS servers use information that is stored in the registry to initialize the service and load any zone data for use at the server. As added options, you can configure the DNS server to boot from a file or, in AD DS environments you can supplement local registry data with zone data that is retrieved for directory-integrated zones that are stored in the Active Directory database. If you use the boot file method, the file that is used must be a text file named Boot, which is located on this computer in the %systemroot%\Windows\System32\Dns folder.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To change the boot method used by the DNS server

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable DNS server, and then click Properties.

  3. Click the Advanced tab.

  4. In the Load zone data on startup list, select From registry, From file, or From Active Directory and registry.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.


Configuring Multihomed Servers

Configuring multihomed servers

For multihomed DNS servers (that is, DNS servers with more than one IP address), you can configure the DNS Server service to selectively enable and bind only to IP addresses that you specify by using DNS Manager. This allows you to ensure that only servers and clients configured to use the specified IP addresses can successfully send queries to the DNS server. For proxy servers that are connected to the Internet, for example, you can use this to ensure that only clients on the internal network can access DNS data. By default, the DNS Server service binds to all IP interfaces that are configured for the computer. These interfaces can include the following:

  • Any additional IP addresses that are configured for a single network connection

  • Individual IP addresses that are configured for each separate connection where more than one network connection is installed on the server

For multihomed DNS servers, you can restrict DNS support for selected IP addresses. When this feature is enabled, the DNS Server service listens for and answers only the DNS requests that are sent to the IP addresses that are specified on the Interface tab in the server properties.

When to specify interfaces

By default, the DNS Server service listens on all IP addresses and accepts all client requests that are sent to its default service ports (UDP 53 or TCP 53). If you do not want the DNS server to respond to requests received on certain addresses, for example if those addresses correspond to external interfaces, you can configure the DNS server to respond to requests received on only some of its interfaces.

Additional considerations for multihoming DNS servers

When you configure additional IP addresses and enable them to be used with a DNS server, consider the following:

  • Additional system resources are consumed at the server computer.

  • Although DNS provides the means to configure multiple IP addresses for use with any of your installed network adapters, there is no performance benefit for doing so.

  • Even if the DNS server is handling multiple zones registered for Internet use, it is not necessary or required by the Internet registration process to have different IP addresses registered for each zone.

Given these considerations:

  • Be aware that, when you add IP addresses for use with DNS servers, each additional address might only slightly increase server performance. In instances in which a large overall number of IP addresses are enabled for use, server performance can be degraded noticeably.

  • In general, when you add network adapter hardware to the server computer, assign only a single primary IP address for each network connection.

  • Whenever possible, remove nonessential IP addresses from existing server TCP/IP configurations.

Note

For more information about how to specify interfaces with the DNS Server service, see Restrict a DNS server to listen only on selected addresses.


Restrict a DNS server to listen only on selected addresses

By default, a DNS Server service that is running on a multihomed computer is configured to listen for DNS queries using all of its IP addresses. You can make the DNS server more secure by limiting the IP addresses that the DNS Server service listens on to the IP address that is used by its DNS clients as their preferred DNS server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Restricting a DNS server to listen only on selected addresses

  • Using the Windows interface

  • Using a command line

To restrict a DNS server to listen only on selected addresses using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS/applicable DNS server

  3. On the Action menu, click Properties.

  4. On the Interfaces tab, click Only the following IP addresses.

  5. In IP address, type an IP address to be enabled for this DNS server , and then click Add.

  6. Repeat the previous step as necessary to specify other server IP addresses to be enabled for this DNS server.

    To remove an IP address from the list, click it, and then click Remove.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • By default, the DNS Server service listens for DNS message communications on all configured IP addresses for the server computer.

  • Server IP addresses that are added here must be managed statically. If you later change or remove the addresses specified here from the TCP/IP configurations that are maintained at this server, update this list accordingly.

  • After you update or revise the list of restricted interfaces, you must stop and restart the DNS server to apply the new list.

  • Restricting the DNS Server service to only listen on specific IP addresses is an effective security measure because only hosts on the same network subnet, or hosts with a router that connects them to that same segment, have access to the server.

To restrict a DNS server to listen only on selected addresses using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ResetListenAddresses [<ListenAddress> ...]

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ResetListenAddresses | Required. Resets the IP addresses of the interfaces on which the DNS server listens.
<ListenAddress> ... | Specifies one or more IP addresses for the interfaces on which you want the DNS server to listen. By default, the DNS Server service listens for DNS message communications on all configured IP addresses for the server computer.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd <ServerName> /ResetListenAddresses /help

Addiditonal considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • Server IP addresses that you add here must be managed statically. If you later change or remove the addresses specified here from the TCP/IP configurations that are maintained at this server, update this list accordingly.

  • After you update or revise the list of restricted interfaces, you must stop and restart the DNS server to apply the new list.

  • Restricting the DNS Server service to listen only on specific IP addresses is an effective security measure because only hosts on the same network subnet, or hosts with a router that connects them to that same segment, have access to the server.

Additional references

  • Start or Stop a DNS Server

  • Configuring Multihomed Servers

  • Security Information for DNS

  • Securing the DNS Server Service

  • Securing DNS Clients


Secure the Server Cache Against Names Pollution

By default, the DNS Server service is secured from cache pollution, which occurs when DNS query responses contain nonauthoritative or malicious data. The Secure cache against pollution option prevents an attacker from successfully polluting the cache of a DNS server with resource records that were not requested by the DNS server. Changing this default setting will reduce the integrity of the responses that are provided by DNS Server service. You can use this procedure to restore the default setting if it was previously changed.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To secure the server cache against names pollution

  1. Open DNS Manager.

  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS/applicable DNS server

  3. On the Action menu, click Properties.

  4. Click the Advanced tab.

  5. In Server options, select the Secure cache against pollution check box, and then click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • The Secure cache against pollution option is enabled by default.

Additional references

  • Security Information for DNS

  • Securing the DNS Server Service


Modify Security for the DNS Server Service on a Domain Controller

You can use this procedure to specify who can administer the DNS Server service when it is running on a domain controller. It does not affect who can administer zones and resource records that are hosted on the server, however.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify security for the DNS Server service on a domain controller

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable server, and then click Properties.

    Where?

    DNS/applicable DNS server

  3. On the Security tab, modify the list of member users or groups that are allowed to administer the applicable server.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Active Directory access control lists (ACLs) are supported for the DNS Server service only when it is running on a domain controller.

Additional references

  • Configure a DNS Server for Use with Active Directory Domain Services

  • Modify Security for a Directory-Integrated Zone

  • Modify Security for a Resource Record


Disable Recursion on the DNS Server

By default, the DNS server performs recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. Recursion is a name-resolution technique in which a DNS server queries other DNS servers on behalf of the requesting client to fully resolve the name and then sends an answer back to the client.

Attackers can use recursion to deny the DNS Server service. Therefore, if a DNS server in your network is not intended to receive recursive queries, recursion should be disabled on that server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Disabling recursion on the DNS server

  • Using the Windows interface

  • Using a command line

To disable recursion on the DNS server using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable DNS server, then click Properties.

    Where?

    DNS/applicable DNS server

  3. Click the Advanced tab.

  4. In Server options, select the Disable recursion check box, and then click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

To disable recursion on the DNS server using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config /NoRecursion {1|0}

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/Config | Required. Specifies that the command configures the specified server.
/NoRecursion | Required. Disables recursion.
{1|0} | Required. To disable recursion, type 1 (off). To enable recursion, type 0 (on). By default, recursion is enabled.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

Additional references

  • Security Information for DNS

  • Securing the DNS Server Service


Updating Root Hints

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

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

For Server A to find Server B—or any other servers that are authoritative for the contoso.com domain, Server A must 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 contoso.com domain. The root hints that Server A uses 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 answer the following questions about your DNS server:

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

  • Is the DNS server used as a root server?

By default, the DNS Server service implements root hints by using a file, Cache.dns, that is stored in the %systemroot%\System32\Dns folder on the server computer. This file normally contains the name server (NS) and host (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.

Root hints are also treated differently when 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 that are managed externally (on the Internet, for example). Even though the DNS server that is used as a forwarder can be located internally on the same network as servers that are using it as a forwarder, it needs hints for the Internet root servers to work properly and resolve external names.

If a DNS server is configured to access other DNS servers, such as through a list of DNS servers that is configured in its client TCP/IP properties for an installed network connection, the DNS Server service is capable of gathering its own root hints during new server configuration. You can use the Configure a DNS Server Wizard to accomplish this.


Update Root Hints on the DNS Server

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

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To update root hints on the DNS server

  1. Open DNS Manager.

  2. In the console tree, click the applicable DNS server.

    Where?

    • DNS/applicable DNS server

  3. On the Action menu, click Properties.

  4. Click the Root Hints tab.

  5. Modify server root hints as follows:

    • To add a root server to the list, click Add, and then specify the name and IP address of the server to be added to the list.

    • To modify a root server in the list, click Edit, and then specify the name and IP address of the server to be modified in the list.

    • To remove a root server from the list, select it in the list, and then click Remove.

    • To copy root hints from a DNS server, click Copy from server, and then specify the IP address of the DNS server from which you want to copy a list of root servers to use in resolving queries. These root hints will not overwrite any existing root hints.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

Additional references

  • Updating Root Hints

  • Security Information for DNS

  • Securing the DNS Server Service


Managing Servers and Zones

You can use DNS Manager, the DNS snap-in in Microsoft Management Console (MMC), to manage the local Domain Name System (DNS) server as well as remote DNS servers. Using DNS Manager or a command line, you can start, stop, or pause a DNS server. You can also pause and restart individual zones that are hosted by the server.

  • Add a Server to DNS Manager

  • Remove a Server from DNS Manager

  • Start or Stop a DNS Server

  • Pause or Resume a Zone


Add a Server to DNS Manager

You can use this procedure to add a local or remote server to DNS Manager so you can manage it.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To add a server to DNS Manager

  1. Open DNS Manager.

  2. On the Action menu, click Connect to DNS Server.

  3. In Connect to DNS Server, click either:

    • This computer, if the server that you want to connect to and manage is located on the same computer that you are using to manage it.

    • The following computer, if the server that you want to connect to and manage is located on a remote computer.

    If you choose to connect to a remote server, specify either its Domain Name System (DNS) computer name or its IP address.

  4. Select the Connect to the specified computer now check box, and then click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

Additional references

  • Remove a Server from DNS Manager


Remove a Server from DNS Manager

You can use this procedure to remove a remote server from DNS Manager.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To remove a server from DNS Manager

  1. Open DNS Manager.

  2. In the console tree, click the applicable Domain Name System (DNS) server.

  3. On the Action menu, click Delete.

  4. When you are prompted to confirm that you want to delete this server from the list, click OK

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

Additional references

  • Add a Server to DNS Manager


Start or Stop a DNS Server

You can use this procedure to control whether the DNS Server service is running and able to respond to queries.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To start or stop a DNS server

  1. Open DNS Manager.

  2. In the console tree, click the applicable Domain Name System (DNS) server.

  3. On the Action menu, point to All Tasks, and then click one of the following:

    • To start the service, click Start.

    • To stop the service, click Stop.

    • To interrupt the service, click Pause.

  4. To stop and then automatically restart the service, click Restart.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • After you pause or stop the service, on the Action menu, in All Tasks, you can click Resume to immediately resume service.

  • When the boot method of your server is configured to load zone data from the registry, changes are applied to DNS servers only when the DNS Server service is initialized again. In this case, if a DNS value is manually changed directly in the registry, the DNS Server service must always be restarted for the new value to be used.

Additional references

  • Add a Server to DNS Manager

  • Change the Boot Method Used by the DNS Server


Pause or Resume a Zone

You can use this procedure to control whether a zone responds to queries or transfer requests.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Pausing or resuming a zone

  • Using the Windows interface

  • Using a command line
To pause or resume a zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, click the applicable zone.

    Where?

    • DNS/applicable DNS server/Forward Lookup Zones (or Reverse Lookup Zones)/applicable zone

  3. On the Action menu, click Properties.

  4. On the General tab, click Pause or Start, and then click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • By default, zones are started when they are created or loaded at the server. After you use this procedure to pause a zone, you must restart the zone before it is available for servicing clients or updating zones.

To pause or resume a zone using a command line

  1. Open a command prompt.

  2. Do one of the following:

    • To pause the zone, type the following command, and then press ENTER:

      dnscmd <ServerName> /ZonePause <ZoneName>
    • To resume the zone, type the following command, and then press ENTER:

      dnscmd <ServerName> /ZoneResume <ZoneName>

Parameter | Description
dnscmd | Manages DNS servers.
ServerName | Required. Specifies the Domain Name System (DNS) host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/ZonePause | Required. Pauses the zone.
/ZoneResume | Required. Resumes the zone.
<ZoneName> | Required. Specifies the fully qualified domain name (FQDN) of the zone.

To view the complete syntax for this command, at a command prompt, type one of the following commands, and then press ENTER:

dnscmd <ServerName> /ZonePause /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Adding Zones

In Domain Name System (DNS), a DNS namespace can be divided into zones. The zones store name information about one or more DNS domains. For each DNS domain name that is included in a zone, the zone becomes the authoritative source for information about that domain.

A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain that is used to create the zone, these domains can either be part of the same zone or belong to another zone.

Forward lookup zones provide name-to-address resolution. Reverse lookup zones are optional, and they provide address-to-name resolution.

You can deploy a specially named forward lookup zone, called GlobalNames, to provide name resolution of single-label names, (that is, names that do not contain the name of the parent domain) when you cannot use Windows Internet Name Service (WINS) or suffix search lists.

The following topics briefly explain zones. These topics also explain how to create zones and remove them from the DNS namespace.

  • Understanding Zones

  • Understanding Zone Types

  • Understanding Reverse Lookup

  • Add a Forward Lookup Zone

  • Add a Reverse Lookup Zone

  • Add a Stub Zone

  • Deploying a GlobalNames Zone


Understanding Zones

In addition to dividing your Domain Name System (DNS) namespace into domains, you can also divide your DNS namespace into zones that store name information about one or more DNS domains. A zone is the authoritative source for information about each DNS domain name that is included in the zone.

A zone starts with a single DNS domain name. If other domains are added below the initial domain, these domains can either be part of the same zone or belong to another zone. That is, when you add a subdomain, you can either include it as part of the original zone, or you can delegate it away to another zone that you create to support the subdomain.

For example, the following illustration 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 must use subdomains, those subdomains must be included in the zone or delegated away to another zone.

Difference between a zone and a domain

In this illustration, the example.microsoft.com domain has 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 must 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 it is managed by the microsoft.com zone.

Zone replication and transfers

Because of the important role that zones play in DNS, they must be available from more than one DNS server on the network so that they can provide availability and fault tolerance. Otherwise, if only a single server is available and that server is not responding, queries for names in the zone can fail. So that additional servers can host a zone, zone transfers are required for replication and synchronization of all copies of the zone that are used at each server that is configured to host the zone.

When a new DNS server is added to the network and it 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. Most earlier DNS server implementations use this same method of full transfer for a zone when the zone requires updating after changes are made to the zone. For DNS servers running Windows Server 2003 and Windows Server 2008, the DNS Server service supports incremental zone transfer, a revised DNS zone transfer process for intermediate changes. Incremental transfers provide a more efficient method of propagating zone changes and updates. Unlike in earlier DNS implementations in which any request for an update of zone data required a full transfer of the entire zone database, with incremental transfer the secondary server can pull only those zone changes that it needs to synchronize its copy of the zone with its source, either a primary or secondary copy of the zone that is maintained by another DNS server.


Understanding Zone Types

The DNS Server service provides for three types of zones:

  • Primary zone

  • Secondary zone

  • Stub zone

Note

If the DNS server is also an Active Directory Domain Services (AD DS) domain controller, primary zones and stub zones can be stored in AD DS. See Understanding Active Directory Domain Services Integration for more information.

The following sections describe each of these zone types.

Primary zone

When a zone that this DNS server hosts is a primary zone, the DNS server is the primary source for information about this zone, and it stores the master copy of zone data in a local file or in AD DS. When the zone is stored in a file, by default the primary zone file is named zone_name.dns and it is located in the %windir%\System32\Dns folder on the server.

Secondary zone

When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary source for information about this zone. The zone at this server must be obtained from another remote DNS server computer that also hosts the zone. This DNS server must have network access to the remote DNS server that supplies this server with updated information about the zone. Because a secondary zone is merely a copy of a primary zone that is hosted on another server, it cannot be stored in AD DS.

Stub zone

When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for information about the authoritative name servers for this zone. The zone at this server must be obtained from another DNS server that hosts the zone. This DNS server must have network access to the remote DNS server to copy the authoritative name server information about the zone.

You can use stub zones to:

  • Keep delegated zone information current. By updating a stub zone for one of its child zones regularly, the DNS server that hosts both the parent zone and the stub zone will maintain a current list of authoritative DNS servers for the child zone.

  • Improve name resolution. Stub zones enable a DNS server to perform recursion using the stub zone's list of name servers, without having to query the Internet or an internal root server for the DNS namespace.

  • Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones, and they are not an alternative for enhancing redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

  • The list of master servers from which the DNS server loads and updates a stub zone. A master server may be a primary or secondary DNS server for the zone. In both cases, it will have a complete list of the DNS servers for the zone.

  • The list of the authoritative DNS servers for a zone. This list is contained in the stub zone using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple servers, and it can be changed anytime.


Understanding Reverse Lookup

In most Domain Name System (DNS) lookups, clients typically perform a forward lookup, which is a search that is based on the DNS name of another computer as it is stored in a host (A) resource record. This type of query expects an IP address as the resource data for the answered response.

DNS also provides a reverse lookup process, in which clients use a known IP address and look up a computer name based on its address. A reverse lookup takes the form of a question, such as "Can you tell me the DNS name of the computer that uses the IP address 192.168.1.20?"

DNS was not originally designed to support this type of query. One problem in supporting the reverse query process is the difference in how the DNS namespace organizes and indexes names and how IP addresses are assigned. If the only method to answer the previous question is to search in all domains in the DNS namespace, a reverse query would take too long and require too much processing to be useful.

To solve this problem, a special domain, the in-addr.arpa domain, was defined in the DNS standards and reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries. To create the reverse namespace, subdomains within the in-addr.arpa domain are formed, using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses.

This reversed ordering of the domains for each octet value is necessary because, unlike DNS names, when IP addresses are read from left to right, they are interpreted in the opposite manner. When an IP address is read from left to right, it is viewed from its most generalized information (an IP network address) in the first part of the address to the more specific information (an IP host address) that is contained in the last octets.

For this reason, the order of IP address octets must be reversed when the in-addr.arpa domain tree is built. The IP addresses of the DNS in-addr.arpa tree can be delegated to organizations as they are assigned a specific or limited set of IP addresses within the Internet-defined address classes.

Finally, the in-addr.arpa domain tree, as it is built into DNS, requires an additional resource record type—the pointer (PTR) resource record—to be defined. This resource record creates a mapping in the reverse lookup zone that typically corresponds to a named host (A) resource record for the DNS computer name of a host in its forward lookup zone.

The in-addr.arpa domain applies to all TCP/IP networks that are based on Internet Protocol version 4 (IPv4) addressing. The New Zone Wizard automatically assumes that you are using this domain when you create a new reverse lookup zone.

If you are installing DNS and configuring reverse lookup zones for an Internet Protocol version 6 (IPv6) network, you can specify an exact name in the New Zone Wizard. This way, you can create reverse lookup zones in DNS Manager that can support IPv6 networks, which use a different special domain name, the ip6.arpa domain.

Additional information is available about IPv6 and DNS, including examples of how to create and use ip6.arpa domain names, in Request for Comments (RFC) 3596, "DNS Extensions to support IP version 6." For more information, refer directly to this RFC, which you can find on the RFC Editor Web site (http://go.microsoft.com/fwlink/?LinkId=240).

Example: reverse query (for IPv4 networks)

The following illustration shows an example of a reverse query that is initiated by a DNS client to learn the name of another host (host-a) based on its IP address: 192.168.1.20.

Example: DNS reverse lookup

The reverse query process follows these steps:

  1. The client queries the DNS server for a pointer (PTR) resource record that maps to the IP address of 192.168.1.20 for host-a.

    Because the query is for pointer (PTR) resource records, the resolver reverses the address and appends the in-addr.arpa domain to the end of the reverse address. This forms the fully qualified domain name (FQDN) (20.1.168.192.in-addr.arpa.) to be searched in a reverse lookup zone.

  2. After it is located, the authoritative DNS server for 20.1.168.192.in-addr.arpa can respond with the pointer (PTR) resource record information. This includes the DNS domain name for host-a, which completes the reverse lookup process.

Remember that, if the queried reverse name is not answerable from the DNS server, normal DNS resolution (either recursion or iteration) can be used to locate a DNS server that is authoritative for the reverse lookup zone and that contains the queried name. In this sense, the name resolution process that is used in a reverse lookup is identical to that of a forward lookup.

Inverse queries

Use of inverse queries is an outdated practice, originally proposed as part of the DNS standard to look up a host name based on its IP address. They use a nonstandard DNS query operation, and their use is limited to some of the earlier versions of Nslookup, a command-line utility for troubleshooting and testing the DNS Server service.

The DNS Server service recognizes and accepts inverse query messages, answering them with a fake inverse query response. For DNS servers running in Windows NT® Server 4.0, this support is available by default if the server computer has been updated to Service Pack 4 (SP4) or later.

Note

The configuration of pointer (PTR) resource records and reverse lookup zones for identifying hosts by reverse query is strictly an optional part of the DNS standard implementation. You are not required to use reverse lookup zones, although for some networked applications, they are used to perform security checks.


Add a Forward Lookup Zone

Forward lookup zones support the primary function of Domain Name System (DNS), that is, the resolution of host names to IP addresses. For more information, see Understanding Zone Types.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Adding a forward lookup zone

  • Using the Windows interface

  • Using a command line
To add a forward lookup zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard.

  3. Follow the instructions to create a new primary zone, secondary zone, or stub zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To add a forward lookup zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneAdd <ZoneName> {/Primary|/DsPrimary|/Secondary|/Stub|/DsStub} [/file <FileName>] [/load] [/a <AdminEmail>] [/DP <FQDN>]

Parameter Description

dsncmd

Manages DNS servers.

<ServerName>

Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)

/ZoneAdd

Required. Adds a zone.

<ZoneName>

Required. Specifies the fully qualified domain name (FQDN) of the zone.

/Primary|/DsPrimary|/Secondary|/Stub|/DsStub

Required. Specifies the type of zone. /DsPrimary and /DsStub specify an Active Directory–integrated zone type.

/file

Required for /Primary. Specifies a file for the new zone. This parameter is not valid for the /DsPrimary zone type.

<FileName>

Required for /Primary. Specifies the name of the zone file. This parameter is not valid for the /DsPrimary zone type.

/load

Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically. This parameter does not apply to /DsPrimary.

/a

Adds an administrator e-mail address for the zone.

<AdminEmail>

Specifies the administrator e-mail name for the zone.

/DP

Adds the zone to an application directory partition. You may also use one of the following:

  • /DP /domain—For a domain directory partition (replicates to all DNS servers in the domain).

  • /DP /forest—For a forest directory partition (replicates to all DNS servers in the forest).

  • /DP /legacy—For a legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains that have legacy Windows 2000 Server domain controllers.

<FQDN>

Specifies the FQDN of the directory partition.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Add a Reverse Lookup Zone

Reverse lookup zones support the resolution of IP addresses to host names. Although they are optional in most networks, reverse lookup zones might be necessary for certain secure applications that require the validation of IP addresses. For more information, see Understanding Zone Types.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Adding a reverse lookup zone

  • Using the Windows interface

  • Using a command line
To add a reverse lookup zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click a Domain Name System (DNS) server, and then click New Zone to open the New Zone Wizard.

  3. Follow the instructions to create a new reverse lookup zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To add a reverse lookup zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

dnscmd <ServerName> /ZoneAdd <ZoneName> {/Primary|/DsPrimary} [/file <FileName>] [/load] [/a <AdminEmail>] [/DP <FQDN>]

Parameter Description

dnscmd

The command-line tool for managing DNS servers.

<ServerName>

Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)

/ZoneAdd

Required. Adds a zone.

<ZoneName>

Required. Specifies the fully qualified domain name (FQDN) of the in-addr.arpa domain for the zone, for example, 20.1.168.192.in-addr.arpa.

/Primary|/DsPrimary

Required. Specifies the type of zone. To specify an Active Directory–integrated zone, type /DsPrimary.

/file

Required for /Primary. Specifies a file for the new zone. This parameter is not valid for the /DsPrimary zone type.

<FileName>

Required for /Primary. Specifies the name of the zone file. This parameter is not valid for the /DsPrimary zone type.

/load

Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically. This parameter does not apply to /DsPrimary.

/a

Adds an administrator e-mail address for the zone.

<AdminEmail>

Specifies the administrator e-mail name for the zone.

/DP

Adds the zone to an application directory partition. You may also use one of the following:

  • /DP /domain—For a domain directory partition (replicates to all DNS servers in the domain).

  • /DP /forest—For a forest directory partition (replicates to all DNS server in the forest).

  • /DP /legacy—For a legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains that have legacy Windows 2000 Server domain controllers.

<FQDN>

Specifies the FQDN of the directory partition.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Add a Stub Zone

A stub zone is a copy of a zone that contains only those resource records that are necessary to identify the authoritative Domain Name System (DNS) servers for that zone. Typically, you use a stub zone to resolve names between separate DNS namespaces. For more information, see Understanding Zone Types.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Adding a stub zone

  • Using the Windows interface

  • Using a command line
To add a stub zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click a DNS server, and then click New Zone to open the New Zone Wizard.

  3. Follow the instructions to create a new stub zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • The stub zone cannot be hosted on a DNS server that is authoritative for the same zone.

  • If you integrate the stub zone into Active Directory Domain Services(AD DS), you have the option to specify that the DNS server hosting the stub zone uses a local list of master servers when it updates the stub zone's resource records, rather than having the DNS server use the master servers list that is stored in AD DS. If you want to use a local master servers list, you must have the IP addresses of the local master servers.

To add a stub zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneAdd <ZoneName> {/Stub|/DsStub} <MasterIPaddress...> [/file <FileName>] [/load] [/DP <FQDN>]

    Parameter Description

    dsncmd

    The command-line tool for managing DNS servers.

    <ServerName>

    Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)

    /ZoneAdd

    Required. Adds a zone.

    <ZoneName>

    Required. Specifies the fully qualified domain name (FQDN) of the zone.

    /Stub|/DsStub

    Required. Specifies the type of zone. To specify an Active Directory–integrated stub zone, type /DsStub.

    <MasterIPaddress...>

    Required. Specifies one or more IP addresses for the master servers of the stub zone, from which it copies zone data.

    /file

    Adds a file for the new zone.

    <FileName>

    Specifies the name of the zone file.

    /load

    Loads an existing file for the zone. If this parameter is not specified, default zone records are created automatically.

    /DP

    Adds the zone to an application directory partition. You may also use one of the following:

    • /DP /domain—For a domain directory partition (replicates to all DNS servers in the domain).

    • /DP /forest—For a forest directory partition (replicates to all DNS server in the forest).

    • /DP /legacy—For a legacy directory partition (replicates to all domain controllers in the domain). This setting supports domains that have legacy domain controllers running Windows 2000 Server.

    <FQDN>

    Specifies the FQDN of the directory partition.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • The stub zone cannot be hosted on a DNS server that is authoritative for the same zone.

  • If you integrate the stub zone into AD DS, you have the option to specify that the DNS server that hosts the stub zone uses a local list of master servers when it updates the stub zone's resource records, rather than having the DNS server use the master servers list that is stored in AD DS. If you want to use a local master servers list, you must have the IP addresses of the local master servers.


Deploying a GlobalNames Zone

A common requirement in computer networks is the ability to resolve simple, single-label names. The use of single-label names makes it possible for a computer to access hosts such as file and Web servers by using short, easy-to-remember names instead of the fully qualified domain names (FQDNs) that form the default naming convention for Domain Name System (DNS). To make the use of single-label names possible, many networks deploy Windows Internet Name Service (WINS) technology and servers in their environment. As a name resolution protocol, WINS is an alternative to DNS. It is an older service that uses NetBIOS over TCP/IP (NetBT). WINS and NetBT do not support Internet Protocol version 6 (IPv6) protocols; therefore, they are being phased out in many networks.

To help network administrators migrate to DNS for all name resolution, the DNS Server role in Windows Server 2008 supports a specially named zone, called GlobalNames. By deploying a zone with this name, you can have the static, global records with single-label names, without relying on WINS. These single-label names typically refer to records for important, well-known and widely-used servers—servers that are already assigned static IP addresses and that are currently managed by IT-administrators using WINS.

The GlobalNames zone is not designed to be a complete replacement for WINS. You should not use the GlobalNames zone to support the name resolution of records that are dynamically registered in WINS, records which typically are not managed by IT administrators. Support for these dynamically registered records is not scalable, especially for larger customers with multiple domains or multiple forests.

Deciding if you need to deploy a GlobalNames zone

Consider deploying a GlobalNames zone if:

  • You are retiring WINS or you are planning to deploy only IPv6 in your environment, so that all name resolution will depend on DNS.

  • Your need for single-label name resolution is limited to important servers or Web sites that can be statically registered in DNS. (Typically, these names are also configured statically and globally in the WINS database.) Host names cannot be registered in the GlobalNames zone by dynamic updates.

  • You cannot rely on the suffix search lists on client computers to provide single-label name resolution; for example, because the number of target domains is too great or the domains cannot be centrally managed to guarantee that host names will be unique. For more information about using suffix search lists, see Understanding DNS Client Settings.

  • All the DNS servers that are authoritative for your zones are servers running Windows Server 2008. To resolve names that are registered in the GlobalNames zone, all DNS servers that are authoritative for a zone and that serve client query requests must be running Windows Server 2008 and they must either be configured with a local copy of the GlobalNames zone or they must be able to contact remote DNS servers that host the GlobalNames zone.

We also recommend that the GlobalNames zone be integrated with Active Directory Domain Services (AD DS). This integration with AD DS ensures easier management and future scalability.

Deploying a GlobalNames zone

The specific steps for deploying a GlobalNames zone can vary somewhat, depending on the AD DS topology of your network.

Step 1: Create the GlobalNames zone

The first step in deploying a GlobalNames zone is to create the zone on a DNS server that is a domain controller running Windows Server 2008. The GlobalNames zone is not a special zone type; rather, it is simply an AD DS-integrated forward lookup zone that is called GlobalNames. For information about creating a primary forward lookup zone, see Add a Forward Lookup Zone.

Step 2: Enable GlobalNames zone support

The GlobalNames zone is not available to provide name resolution until GlobalNames zone support is explicitly enabled by using the following command on every authoritative DNS server in the forest:

dnscmd <ServerName> /config /enableglobalnamessupport 1

where ServerName is the DNS name or IP address of the DNS server that hosts the GlobalNames zone. To specify the local computer, replace ServerName with a period (.), for example, dnscmd . /config /enableglobalnamessupport 1.

Step 3: Replicate the GlobalNames zone

To make the GlobalNames zone available to all DNS servers and clients in a forest, replicate the zone to all domain controllers in the forest, that is, add the GlobalNames zone to the forest-wide DNS application partition. For more information, see Change the Zone Replication Scope.

If you want to limit the servers that will be authoritative for the GlobalNames zone, you can create a custom DNS application partition for replicating the GlobalNames zone. For more information, see Understanding DNS Zone Replication in Active Directory Domain Services.

Step 4: Populate the GlobalNames zone

For each server that you want to be able to provide single-label name resolution for, add an alias (CNAME) resource record to the GlobalNames zone. For more information, see Add an Alias (CNAME) Resource Record to a Zone.

Step 5: Publish the location of the GlobalNames zone in other forests

If you want DNS clients in other forests to use the GlobalNames zone for resolving names, add service location (SRV) resource records to the forest-wide DNS application partition, using the service name _globalnames._msdcs and specifying the FQDN of the DNS server that hosts the GlobalNames zone. For more information, see Add a Resource Record to a Zone and Service Location (SRV) Resource Record Dialog Box.

In addition, you must run the dnscmd ServerName /config /enableglobalnamessupport 1 command on every authoritative DNS server in the forests that do not host the GlobalNames zone.

Additional considerations

  • By default, an authoritative DNS server uses local zone data first to respond to a query, before trying the GlobalNames zone to see if the name exists. If there is no relevant data in the GlobalNames zone and resolution using suffixes fails, resolution fails over to WINS. Querying local zone data first is a performance optimization.

  • Dynamic updates that are sent to an authoritative DNS server are checked against GlobalNames zone data first before being checked against local zone data. This ensures that GlobalNames zone names remain unique.

  • No software updates are required for clients to enable them to resolve the names that are configured in the GlobalNames zone. Primary DNS suffix, connection-specific suffixes, and the DNS suffix search list continue to work as usual.

  • DNS client registration is not affected unless a computer tries to register a name that is already configured in the GlobalNames zone.

Additional references

  • Understanding Zones

  • Understanding Zone Types

  • Understanding Active Directory Domain Services Integration


Configuring Zone Properties

In Domain Name System (DNS), you can divide a DNS namespace into zones that store name information about one or more DNS domains. For each DNS domain name that is included in a zone, the zone becomes the authoritative source for information about that domain.

A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain that is 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.

  • Delegated away to another zone that is created to support the subdomain.

You can configure a DNS server to host a zone as one of three zone types:

  • A primary zone, for which the DNS server is the primary authority

  • A secondary zone, for which the DNS server maintains a copy of the zone that is transferred from a primary server

  • A stub zone, for which the DNS server provides only the name servers that are authoritative for the zone

You can also configure a zone to use Windows Internet Name Service (WINS) to resolve names, and you can determine how an Active Directory Domain Services (AD DS)–integrated zone is replicated.

  • Understanding Zone Delegation

  • Understanding Zone Types

  • Create a Zone Delegation

  • Enable DNS to Use WINS Resolution

  • Specify Other DNS Servers as Authoritative for a Zone

  • Change the Zone Type

  • Change the Zone Replication Scope

  • Modify Security for a Directory-Integrated Zone

  • Modify Zone Transfer Settings


Understanding Zone Delegation

Domain Name System (DNS) provides the option of dividing up the namespace into one or more zones, which can then be stored, distributed, and replicated to other DNS servers. When you are deciding whether to divide your DNS namespace to make additional zones, consider the following reasons to use additional zones:

  • You want to delegate management of part of your DNS namespace to another location or department in your organization.

  • You want to divide one large zone into smaller zones to distribute traffic loads among multiple servers, improve DNS name resolution performance, or create a more-fault-tolerant DNS environment.

  • You want to extend the namespace by adding numerous subdomains at once, for example, to accommodate the opening of a new branch or site.

If, for any of these reasons, you can benefit from delegating zones, it might make sense to restructure your namespace by adding additional zones. When you are deciding how to structure zones, use a plan that reflects the structure of your organization.

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

When a standard primary zone is first created, all the resource record information is stored as a text file on 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 you are structuring your zones, there are several good reasons to use additional DNS servers for zone replication:

  • Added DNS servers provide zone redundancy, which makes it possible for DNS names in the zone to be resolved for clients if a primary server for the zone stops responding.

  • Added 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 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 illustration, when a new zone for a subdomain (example.microsoft.com) is created, delegation from the parent zone (microsoft.com) is needed.

Example: How zone delegation works

In this example, an authoritative DNS server computer for the newly delegated example.microsoft.com subdomain is named that is based on a derivative subdomain that is included in the new zone (ns1.na.example.microsoft.com). To make this server known to other servers outside the new delegated zone, two resource records are necessary in the microsoft.com zone to complete delegation to the new zone.

These resource records include the following:

  • A name server (NS) resource record to effect the delegation. This resource record advertises that the server named ns1.na.example.microsoft.com is an authoritative server for the delegated subdomain.

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


Create a Zone Delegation

You can divide your Domain Name System (DNS) namespace into one or more zones. You can delegate management of part of your namespace to another location or department in your organization by delegating the management of the corresponding zone. For more information, see Understanding Zone Delegation.

When you delegate a zone, remember that for each new zone that you create, you will need delegation records in other zones that point to the authoritative DNS servers for the new zone. This is necessary both to transfer authority and to provide correct referral to other DNS servers and clients of the new servers that are being made authoritative for the new zone.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Creating a zone delegation

  • Using the Windows interface

  • Using a command line
To create a zone delegation using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable subdomain, and then click New Delegation.

  3. Follow the instructions in the New Delegation Wizard to finish creating the new delegated domain.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • All domains (or subdomains) that appear as part of the applicable zone delegation must be created in the current zone before delegation is performed as described here. As necessary, use DNS Manager to first add domains to the zone before you complete this procedure.

To create a zone delegation using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /RecordAdd <ZoneName> <NodeName> [/Aging] [/OpenAcl] [<Ttl>] NS {<HostName>|<FQDN>}

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Specifies the command to add a resource record.
<ZoneName> | Required. Specifies the fully qualified domain name (FQDN) of the zone.
<NodeName> | Required. Specifies the FQDN of the node in the DNS namespace for which the start of authority (SOA) resource record is added. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
<Ttl> | Specifies the Time To Live (TTL) setting for the resource record. (The default TTL is defined in start of authority (SOA) resource record).
NS | Required. Specifies that you are adding a name server (NS) resource record to the zone that is specified in ZoneName.
<HostName>|<FQDN> | Required. Specifies the host name or FQDN of the new authoritative server.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /RecordAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Enable DNS to Use WINS Resolution

The DNS Server service can use Windows Internet Name Service (WINS) servers to look up names that are not found in the Domain Name System (DNS) domain namespace by checking the NetBIOS namespace that is managed by WINS.

To use WINS lookup integration, two special resource record types—the WINS and WINS-R resource records—are enabled and added to a zone. When the WINS resource record is used, DNS queries that fail to find a matched host (A) resource record in the zone are forwarded to WINS servers that are configured in the WINS resource record. For reverse lookup zones, the WINS-R resource record can be enabled and used to provide a similar benefit for further resolving a reverse query that is not answerable in the reverse in-addr.arpa domain.

Note

As an alternative to using WINS for resolving single-label host names, you can configure DNS client computers to use suffix search lists. You can also deploy a specially named zone, called GlobalNames, to provide name resolution for a limited set of centrally managed host names. For more information about these alternatives to WINS, see Understanding DNS Client Settings and Deploying a GlobalNames Zone.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable DNS to use WINS resolution

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, then click Properties.

  3. Do one of the following:

    • If the applicable zone is a forward lookup zone, on the WINS tab, select the Use WINS forward lookup check box. In IP address, type the IP address of a WINS server to be used for resolution of names that are not found in DNS, and then click Add.

    • If the applicable zone is a reverse lookup zone, on the WINS-R tab, select the Use WINS-R lookup check box. In Domain to append to returned name, type a name.

  4. Select the Do not replicate this record check box for this WINS record, if applicable.

    If you are replicating this zone between DNS servers that do not recognize the WINS or WINS-R resource records, select this check box. This prevents these records from being replicated to these other servers during zone transfers. If this zone will be used in performing zone transfers to BIND servers, this is a critical option because Berkeley Internet Name Domain (BIND) will not recognize WINS records.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • When you enable this option, specified WINS servers that are configured in this procedure are used for final referral of names that are not found in the applicable zone.

  • As an option, you can click Advanced to adjust advanced WINS lookup parameters.


Specify Other DNS Servers as Authoritative for a Zone

Use this procedure to add secondary servers for your existing zones to the name server (NS) record to make them authoritative for the zone. Typically, it may be necessary to perform this procedure at the primary zone only when you add Domain Name System (DNS) servers to act as secondary servers. You can also perform this procedure to specify that these servers are known to be authoritative when they answer queries for zone data. DNS servers automatically add and perform initial configuration of the name server NS resource record for each new primary zone that is added to the server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Specifying other DNS servers as authoritative for a zone

  • Using the Windows interface

  • Using a command line
To specify other DNS servers as authoritative for a zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Properties.

  3. Click the Name Servers tab.

  4. Click Add.

  5. Specify additional DNS servers by their names and IP addresses, and then click Add to add them to the list.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To specify other DNS servers as authoritative for a zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /RecordAdd <ZoneName> <NodeName> [/Aging] [/OpenAcl] [<Ttl>] NS {<HostName>|<DomainName>}

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds a resource record.
<ZoneName> | Required. Specifies the fully qualified domain name (FQDN) of the zone.
<NodeName> | Required. Specifies the FQDN of the node in the DNS namespace for which the start of authority (SOA) record is added. You can also type the node name relative to ZoneName or @, which specifies the zone's root node.
/Aging | If you use this parameter, this resource record can be aged and scavenged. If you do not use this parameter, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
<Ttl> | Specifies the Time-To-Live (TTL) setting for the resource record. (The default TTL is defined in SOA resource record).
NS | Required. Specifies that you are adding a name server (NS) resource record to the zone that is specified in ZoneName.
<HostName>|<FQDN> | Required. Specifies the host name or FQDN of the new authoritative server.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /RecordAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Change the Zone Type

You can use this procedure to change make a zone a primary, secondary, or stub zone. You can also use it to integrate a zone with Active Directory Domain Services (AD DS). For more information, see Understanding Zone Types.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Changing the zone type

  • Using the Windows interface

  • Using a command line
To change the zone type using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then select Properties.

  3. On the General tab, note the current zone type, and then click Change.

  4. In Change Zone Type, select a zone type other than the current zone type, and then click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • You can select either Primary zone, Secondary zone or Stub zone. When you select the secondary or stub zone types, you must specify the IP address of another Domain Name System (DNS) server to be used as the source for obtaining updated information for the zone.

  • If the DNS server computer is operating as a domain controller, the option to store the zone in AD DS is available. This option is not otherwise available. When this zone type is selected for use, zone data is stored and replicated as part of the AD DS database.

    Note

    You cannot change the zone type (primary, secondary, or stub) and the method for storing the zone at the same time. You must perform the two operations separately.

  • Changing a zone from a secondary to primary type can affect other zone activities, including management of dynamic updates and zone transfers and the use of DNS notify lists to notify other servers about changes in the zone.

  • Changing a zone from stub to primary or the reverse is not recommended. This contradicts the purpose of stub zones.

  • Changing the DNS zone type or storage can be time consuming for large zones.

To change the zone type using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneResetType <ZoneName Property> [<MasterIPaddress...>] [/file <FileName>] {/OverWrite_Mem|/OverWrite_Ds|/DirectoryPartition <FQDN>}

Parameter Description

dnscmd

Specifies the name of the command-line tool for managing DNS servers.

<ServerName>

Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)

<ZoneName>

Required. Specifies the fully qualified domain name (FQDN) of zone.

<Property>

Required. One of the following zone types:

  • /Primary

    Standard primary zone. The /file FileName option is required.

  • /DsPrimary

    AD DS-integrated primary zone. If the zone is not already a primary zone, you must convert it to a primary zone (using /Primary) before you use this parameter to integrate the zone with AD DS.

  • /Secondary

    Secondary zone. You must specify at least one MasterIPaddress.

  • /Stub

    Stub zone. You must specify at least one MasterIPaddress. If the zone is an AD DS-integrated primary zone, you must use /DsStub to convert it to an AD DS-integrated stub zone before you use this parameter.

  • /DsStub

    AD DS -integrated stub zone. You must specify at least one MasterIPaddress. If the zone is not already a stub zone, you must convert it to a stub zone (using /Stub) before you use this parameter to integrate the zone with AD DS.

/file <FileName>

Required for /Primary. Specifies the name of a file for the new zone. This parameter is not valid for the /DsPrimary zone type.

<MasterIPaddress...>

Required for /Secondary, /Stub and /DsStub. Specifies one or more IP addresses for the master servers of the secondary zone or stub zone, from which zone data is copied.

/OverWrite_Mem | /OverWrite_Ds | /DirectoryPartition <FQDN>

/OverWrite_Mem overwrites existing DNS data using the data in AD DS. /OverWrite_Ds overwrites Active Directory data with data in DNS. /DirectoryPartition stores the new zone in the application directory partition that is specified by FQDN, such as DomainDnsZones.corp.widgets.tailspintoys.com.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneResetType /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • You can select either primary zones, secondary zones, or stub zones. When you select the secondary or stub zone type, specify the IP address of another DNS server to be used as the source for obtaining updated information for the zone.

  • If the DNS server computer is operating as a domain controller, you can use the /DsPrimary or /DsStub parameters. These options are not otherwise available. When either zone type is selected for use, zone data is stored and replicated as part of the AD DS database.

    Note

    Before you use these options, you must first convert the zone to the appropriate type, if necessary. That is, the zone must already be a primary zone before you can use /DsPrimary to integrate the zone with AD DS. Similarly, the zone must already be a stub zone before you can use /DsStub to integrate the zone with AD DS.

  • Changing a zone from a secondary zone to a primary zone can affect other zone activities, including management of dynamic updates and zone transfers, and the use of DNS notify lists to notify other servers about changes in the zone.

  • Changing a zone from a stub zone to a primary zone or the reverse is not recommended. This contradicts the purpose of stub zones.


Change the Zone Replication Scope

You can use the following procedure to change the replication scope for a zone. Only Active Directory Domain Services (AD DS)–integrated primary and stub forward lookup zones can change their replication scope. Secondary forward lookup zones cannot change their replication scope.

Membership in Administrators, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Changing zone replication scope

  • Using the Windows interface

  • Using a command line
To change zone replication scope using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Properties.

  3. On the General tab, note the current zone replication type, and then click Change.

  4. Select a replication scope for the zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To change zone replication scope using the command line

  • At a command prompt, type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneChangeDirectoryPartition <ZoneName> <NewPartitionName>

    Parameter Description

    dnscmd

    Specifies the name of the command-line tool for managing DNS servers.

    <ServerName>

    Required. Specifies the Domain Name System (DNS) host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)

    /ZoneChangeDirectoryPartition

    Required. Changes a zone's replication scope.

    <ZoneName>

    Required. Specifies the fully qualified domain name (FQDN) of the zone.

    <NewPartitionName>

    Required. The FQDN of the DNS application directory partition where the zone will be stored.

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Modify Security for a Directory-Integrated Zone

You can manage the discretionary access control list (DACL) on the DNS zones that are stored in Active Directory Domain Services (AD DS). You can use the DACL to control the permissions for the Active Directory users and groups that may control the DNS zones.

Membership in DnsAdmins or Domain Admins in AD DS, or the equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify security for a directory-integrated zone

  1. Open DNS Manager.

  2. In the console tree, click the applicable zone.

    Where?

    • DNS/applicable DNS server/Forward Lookup Zones (or Reverse Lookup Zones)/applicable zone

  3. On the Action menu, click Properties.

  4. On the General tab, verify that the zone type is Active Directory-integrated.

  5. On the Security tab, modify the list of member users or groups that are allowed to securely update the applicable zone and reset their permissions as needed.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Secure dynamic updates are supported only for zones that are stored in AD DS.

  • The security settings determine who can administer the zone, but they do not affect dynamic updates to the zone. To apply security settings for dynamic updates, see "Additional references."

Additional references

  • Modify Security for a Resource Record

  • Security Information for DNS

  • Securing DNS zones


Modify Zone Transfer Settings

You can use the following procedure to control whether a zone will be transferred to other servers and which servers can receive the zone transfer.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Modifying zone transfer settings

  • Using the Windows interface

  • Using a command line

To modify zone transfer settings using the Windows interface

  1. Open DNS Manager.

  2. Right-click a DNS zone, and then click Properties.

  3. On the Zone Transfers tab, do one of the following:

    • To disable zone transfers, clear the Allow zone transfers check box.

    • To allow zone transfers, select the Allow zone transfers check box.

  4. If you allowed zone transfers, do one of the following:

    • To allow zone transfers to any server, click To any server.

    • To allow zone transfers only to the DNS servers that are listed on the Name Servers tab, click Only to servers listed on the Name Servers tab.

    • To allow zone transfers only to specific DNS servers, click Only to the following servers, and then add the IP address of one or more DNS servers.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • To improve the security of your DNS infrastructure, allow zone transfers only for either the DNS servers in the name server (NS) resource records for a zone or for specified DNS servers. If you allow any DNS server to perform a zone transfer, you are allowing internal network information to be transferred to any host that can contact your DNS server.

To modify zone transfer settings using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneResetSecondaries <ZoneName> {/NoXfr | /NonSecure | /SecureNs | /SecureList [<SecondaryIPAddress...>]}

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
<ZoneName> | Required. Specifies the fully qualified domain name (FQDN) of the zone.
/NoXfr | Disables zone transfers for the zone.
/NonSecure | Permits zone transfers to any DNS server.
/SecureNs | Permits zone transfers only to DNS servers that are listed in the zone using name server (NS) resource records.
/SecureList | Permits zone transfers only to DNS servers that are specified by SecondaryIPAddress.
<SecondaryIPAddress> | Required, if /SecureList is specified. A list of one or more IP addresses for DNS servers that are permitted to obtain zone transfers.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneResetSecondaries /?

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • To improve the security of your DNS infrastructure, allow zone transfers only for either the DNS servers in the name server NS resource records for a zone or for specified DNS servers. If you allow any DNS server to perform a zone transfer, you are allowing internal network information to be transferred to any host that can contact your DNS server.

Additional references

  • Security Information for DNS


Managing Resource Records

Resource records contain the information that a zone maintains about the resources (such as hosts) that the zone contains. A typical resource record consists of the name (host) of the resource record owner, information about how long the resource record can remain in the cache, the resource record type (such as a host (A) resource record), and data that is specific to the record type (such as the host's address). You can add resource records directly, or they can be added automatically when Windows-based, Dynamic Host Configuration Protocol (DHCP)–enabled clients join a network—a process that is known as dynamic update.

  • Adding Resource Records

  • Understanding Dynamic Update

  • Allow Dynamic Updates

  • Allow Only Secure Dynamic Updates

  • Add a Resource Record to a Zone

  • Add an Alias (CNAME) Resource Record to a Zone

  • Modify Security for a Resource Record

  • Use Aging and Scavenging


Adding Resource Records

After you create a zone, you must add additional resource records to it. The most common resource records that you add include the following:

  • Host (A) resource records: for mapping a Domain Name System (DNS) domain name to an IP address that is used by a computer.

  • Alias (CNAME) resource records: for mapping an alias DNS domain name to another primary or canonical name.

  • Mail exchanger (MX) resource records: for mapping a DNS domain name to the name of a computer that exchanges or forwards mail.

  • Pointer (PTR) resource records: for mapping a reverse DNS domain name that is based on the IP address of a computer that points to the forward DNS domain name of that computer.

  • Service location (SRV) resource records: 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.

  • Other resource records as needed.

Host (A) resource records

You use host (A) resource records in a zone to associate DNS domain names of computers (or hosts) to their IP addresses. You can add them to a zone in several ways:

  • You can manually create a host (A) resource record for a static TCP/IP client computer by using DNS Manager.

  • Windows clients and servers use the DHCP Client service to dynamically register and update their own host (A) resource records in DNS when an IP configuration change occurs.

  • Dynamic Host Configuration Protocol (DHCP)–enabled client computers running earlier versions of Microsoft operating systems can have their host (A) resource records registered and updated by proxy if they obtain their IP lease from a qualified DHCP server. (Only the Windows 2000, Windows Server 2003, and Windows Server 2008 DHCP Server service support this feature.)

Not all computers require the host (A) resource records, but computers that share resources on a network need them. Any computer that shares resources and must be identified by its DNS domain name must use host (A) resource records to provide DNS name resolution to the IP address for the computer.

Most host (A) resource records 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 the majority of resource records in a zone database.

Alias (CNAME) resource records

Alias (CNAME) resource records are also sometimes called canonical name resource records. With these records, you can use more than one name to point to a single host, which makes it easy to do such things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered with alias (CNAME) resource records that map to the DNS host name (such as server-1) for the server computer that hosts these services.

We recommend alias (CNAME) resource records for the following scenarios:

  • When a host that is specified in an host (A) resource record in the same zone must be renamed

  • When a generic name for a well-known server, such as www, must resolve to a group of individual computers (each with individual host (A) resource records) that provide the same service, for example, in a group of redundant Web servers.

When you rename a computer with an existing host (A) resource record in the zone, you can use an alias (CNAME) resource record temporarily to allow a grace period for users and programs to switch from the old computer name to the new one, as follows:

  • For the new DNS domain name of the computer, add a new host (A) resource record to the zone.

  • For the old DNS domain name, add an alias (CNAME) resource record that points to the new host (A) resource record.

  • Remove the original host (A) resource record for the old DNS domain name (and its associated pointer (PTR) resource record, if applicable) from the zone.

When you use an alias (CNAME) resource record 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 alias (CNAME) resource record and later its associated host (A) resource record is deleted, the alias (CNAME) resource record can waste server resources trying to resolve queries for a name that is no longer used on the network.

The most common or popular use of an alias (CNAME) resource record is to provide a permanent DNS aliased domain name for generic name resolution of a service-based name, such as www.tailspintoys.com, to more than one computer or one IP address on a Web server. The following example shows the basic syntax of an alias (CNAME) resource record:

alias_name IN CNAME primary_canonical_name

In this example, a computer named host-a.tailspintoys.com functions as both a Web server named www.tailspintoys.com. and as an FTP server named ftp.tailspintoys.com. To achieve the intended objective of naming this computer, you can add the following CNAME entries in the tailspintoys.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 alias (CNAME) resource record in the zone for ftp.tailspintoys.com and add an additional host (A) resource record to the zone for the new computer hosting the FTP server.

Based on the earlier example, if the new computer is named host-b.tailspintoys.com, the new and revised host (A) and alias (CNAME) resource records appear 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

E-mail applications use the mail exchanger (MX) resource record to locate a mail server based on a DNS domain name in the destination address for the e-mail recipient of a message. For example, a DNS query for the name example.tailspintoys.com can be used to find a mail exchanger (MX) resource record, which makes it possible for an e-mail application to forward or exchange mail to a user with the e-mail address user@tailspintoys.com.

The mail exchanger (MX) resource record shows the DNS domain name for the computer or computers that process mail for a domain. If multiple mail exchanger (MX) resource records 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 example shows the basic syntax of a mail exchanger (MX) resource record:

mail_domain_name IN MX preference mailserver_host

Using the mail exchanger (MX) resource records in the following example for tailspintoys.com zone, mail that is addressed to user@tailspintoys.com is delivered to user@mailserver0.tailspintoys.com first, if possible. If this server is unavailable, the resolver client can then use user@mailserver1.tailspintoys.com instead.

@         IN  MX   1    mailserver0
@         IN  MX   2    mailserver1

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

Pointer (PTR) resource records

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

Pointer (PTR) resource records can be added to a zone in several ways:

  • You can manually create a pointer (PTR) resource record for a static TCP/IP client computer using DNS, either as a separate procedure or as part of the procedure for creating a host (A) resource record.

  • Computers use the DHCP Client service to dynamically register and update their pointer (PTR) resource record in DNS when an IP configuration change occurs.

  • All other Dynamic Host Configuration Protocol (DHCP)-enabled client computers can have their pointer (PTR) resource records registered and updated by the DHCP server if they obtain their IP lease from a qualified server. The Windows 2000, Windows Server 2003, and Windows Server 2008 DHCP Server service provides this capability.

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

Service location (SRV) resource records

Service location (SRV) resource records are required for location of Active Directory domain controllers. Typically, you can avoid manual administration of service location (SRV) resource records when you install Active Directory Domain Services (AD DS).

By default, the Active Directory Domain Services Installation Wizard attempts to locate a DNS server based on the list of preferred or alternate DNS servers, which are 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 service location (SRV) resource record is contacted, the configuration process is complete. (This is also true for other resource records that are related to registering AD DS as a service in DNS.)

If, during the installation, a DNS server that can accept updates for the DNS domain name that is used to name your 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 choose for your first domain in the forest is example.tailspintoys.com, you can add and configure a zone that is rooted at the DNS domain name of example.tailspintoys.com to use with the DNS server that is running on the new domain controller.

In the future, the service location (SRV) resource record may 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 resource records

Other additional resource records are supported by Windows Server 2008 DNS and are used less frequently in most zones. You can add these additional types of resource records as necessary with DNS Manager.


Understanding Dynamic Update

Domain Name System (DNS) client computers can use dynamic update to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.

The DNS Client service and the DNS Server service support the use of dynamic updates, as described in Request for Comments (RFC) 2136, "Dynamic Updates in the Domain Name System." The DNS Server service allows dynamic update to be enabled or disabled on a per-zone basis at each server that is configured to load either a standard primary or directory-integrated zone. By default, the DNS Client service dynamically updates host (A) resource records in DNS when the service is configured for TCP/IP.

How client and server computers update their DNS names

By default, computers that are statically configured for TCP/IP attempt to dynamically register host (A) resource records and pointer (PTR) resource records for IP addresses that are configured and used by their installed network connections. By default, all computers register records based on their fully qualified domain name (FQDN).

The primary full computer name, an FQDN, is based on the primary DNS suffix of a computer, appended to its computer name.

Additional considerations:

  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone that is named with a single-label name is considered to be a TLD zone, for example, com, edu, blank, my-company. To configure a DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or you can modify the registry.

  • By default, the primary DNS suffix portion of a computer's FQDN is the same as the name of the Active Directory Domain Services (AD DS) domain to which the computer is joined. To allow the use of different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by modifying the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is managed by the domain administrator using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Dynamic updates can be sent for any of the following reasons or events:

  • An IP address is added, removed, or modified in the TCP/IP properties configuration for any one of the installed network connections.

  • An IP address lease changes or renews with the DHCP server any one of the installed network connections. For example, when the computer is started or if the ipconfig /renew command is used.

  • The ipconfig /registerdns command is used to manually force a refresh of the client name registration in DNS.

  • At startup time, when the computer is turned on.

  • A member server is promoted to a domain controller.

When one of the previous events triggers a dynamic update, the DHCP Client service (not the DNS Client service) sends updates. This is designed so that if a change to the IP address information occurs because of DHCP, corresponding updates in DNS are performed to synchronize name-to-address mappings for the computer. The DHCP Client service performs this function for all network connections on the system, including connections that are not configured to use DHCP.

Example: How dynamic update works

Typically, dynamic updates are requested when either a DNS name or an IP address changes on the computer. For example, supposethat a client named oldhost is first configured in System properties with the following names.

Computer name | oldhost
DNS domain name of computer | tailspintoys.com
Full computer name | oldhost.tailspintoys.com

In this example, no connection-specific DNS domain names are configured for the computer. Later, the computer is renamed from oldhost to newhost, which results in the following name changes on the system.

Computer name | newhost
DNS domain name of computer | tailspintoys.com
Full computer name | newhost.tailspintoys.com

After you apply the name change in System properties, you are prompted to restart the computer. When the computer restarts Windows, the DHCP Client service performs the following sequence to update DNS:

  1. The DHCP Client service sends a start of authority (SOA)–type query using the DNS domain name of the computer.

    The client computer uses the currently configured FQDN of the computer (such as newhost.tailspintoys.com) as the name that is specified in this query.

  2. The authoritative DNS server for the zone that contains the client FQDN responds to the SOA-type query.

    For standard primary zones, the primary server (owner) that is returned in the SOA query response is fixed and static. It always matches the exact DNS name as it appears in the SOA resource record that is stored with the zone. If, however, the zone being updated is directory integrated, any DNS server that is loading the zone can respond and dynamically insert its own name as the primary server (owner) of the zone in the SOA query response.

  3. The DHCP Client service then attempts to contact the primary DNS server.

    The client processes the SOA query response for its name to determine the IP address of the DNS server that is authorized as the primary server for accepting its name. It then proceeds to perform the following sequence of steps as needed to contact and dynamically update its primary server:

    1. It sends a dynamic update request to the primary server that is determined in the SOA query response.

      If the update succeeds, no further action is taken.

    2. If this update fails, the client next sends a name server (NS)–type query for the zone name that is specified in the SOA record.

    3. When it receives a response to this query, it sends an SOA query to the first DNS server that is listed in the response.

    4. After the SOA query is resolved, the client sends a dynamic update to the server that is specified in the returned SOA record.

      If the update succeeds, no further action is taken.

    5. If this update fails, the client repeats the SOA query process by sending to the next DNS server that is listed in the response.

  4. After the primary server that can perform the update is contacted, the client sends the update request and the server processes it.

    The contents of the update request include instructions to add host (A) (and possibly pointer (PTR)) resource records for newhost.tailspintoys.com and to remove these same record types for oldhost.tailspintoys.com, the name that was registered previously.

    The server also checks to ensure that updates are permitted for the client request. For standard primary zones, dynamic updates are not secured; therefore, any client attempt to update succeeds. For AD DS-integrated zones, updates are secured and performed using directory-based security settings.

Dynamic updates are sent or refreshed periodically. By default, computers send a refresh once every seven days. If the update results in no changes to zone data, the zone remains at its current version and no changes are written. Updates result in actual zone changes or increased zone transfer only if names or addresses actually change.

When the DHCP Client service registers host (A) and pointer (PTR) resource records for a computer, it uses a default caching Time to Live (TTL) of 15 minutes for host records. This determines how long other DNS servers and clients cache a computer's records when the records are included in a query response.

Secure dynamic update

DNS update security is available only for zones that are integrated into AD DS. When you directory-integrate a zone, access control list (ACL) editing features are available in DNS Manager so that you can add or remove users or groups from the ACL for a specified zone or resource record.

By default, dynamic update security for DNS servers and clients can be handled as follows:

  • DNS clients attempt to use unsecured dynamic update first. If an unsecured update is refused, clients try to use secure update.

    Also, clients use a default update policy that permits them to attempt to overwrite a previously registered resource record, unless they are specifically blocked by update security.

  • After a zone becomes AD DS-integrated, DNS servers running Windows Server® 2008 default to allowing only secure dynamic updates.

    When you use standard zone storage, the default for the DNS Server service is to not allow dynamic updates on its zones. For zones that are either directory-integrated or that use standard file-based storage, you can change the zone to allow all dynamic updates, which permits all updates to be accepted.


Allow Dynamic Updates

Domain Name System (DNS) client computers can use dynamic update to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.

Dynamic updates can be both secure and nonsecure. For more information, see Understanding Dynamic Update.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Allowing dynamic updates

  • Using the Windows interface

  • Using a command line
To allow dynamic updates using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Properties.

  3. On the General tab, verify that the zone type is either Primary or Active Directory-integrated.

  4. In Dynamic Updates, click Nonsecure and secure.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Dynamic update is a Request for Comments (RFC)–compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATES)."

To allow dynamic updates using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config {<ZoneName>|..AllZones} /AllowUpdate {1|0}

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Configures the specified zone.
<ZoneName>|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones that are hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/AllowUpdate | Required. Enables dynamic updates for the specified zones.
1|0 | Configures dynamic update. To allow dynamic updates, enter a value of 1. To not allow dynamic updates, enter a value of 0.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATES)."

Additional references

  • Understanding Dynamic Update

  • Allow Only Secure Dynamic Updates


Allow Only Secure Dynamic Updates

Domain Name System (DNS) client computers can use dynamic update to register and dynamically update their resource records with a DNS server whenever changes occur. This reduces the need for manual administration of zone records, especially for clients that frequently move or change locations and use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address.

Dynamic updates can be secure or nonsecure. DNS update security is available only for zones that are integrated into Active Directory Domain Services (AD DS). After you directory-integrate a zone, access control list (ACL) editing features are available in DNS Manager so that you can add or remove users or groups from the ACL for a specified zone or resource record.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Allowing only secure dynamic updates

  • Using the Windows interface

  • Using a command line
To allow only secure dynamic updates using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Properties.

  3. On the General tab, verify that the zone type is Active Directory-integrated.

  4. In Dynamic Updates, click secure only.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Secure dynamic update is supported only for AD DS-integrated zones. If the zone type is configured differently, you must change the zone type and directory-integrate the zone before securing it for DNS dynamic updates.

  • Dynamic update is a Request for Comments (RFC)–compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."

  • By default, the DNS server allows a zone transfer only to authoritative DNS servers that are listed in the name server (NS) resource records for the zone.

To allow only secure dynamic updates using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config {<ZoneName>|..AllZones} /AllowUpdate 2

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Configures the specified zone.
<ZoneName>|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones that are hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/AllowUpdate | Required. Enables the zone to perform dynamic updates.
2 | Required. Configures the server to allow secure update. If you exclude the 2, the zone will be set to perform standard dynamic updates only.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

  • Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."

  • By default, the DNS server allows a zone transfer only to authoritative DNS servers that are listed in the name server (NS) resource records for the zone.

Additional references

  • Understanding Dynamic Update

  • Allow Dynamic Updates


Add a Resource Record to a Zone

After you create a zone, typically you add additional resource records to it. The most common resource records to be added are the following:

  • Host (A) resource record for mapping a Domain Name System (DNS) domain name to an IP address that a computer uses.

  • Alias (CNAME) resource record for mapping an alias DNS domain name to another primary or canonical name.

  • Mail exchanger (MX) resource record for mapping a DNS domain name to the name of a computer that exchanges or forwards mail.

  • Pointer (PTR) resource record for mapping a reverse DNS domain name that is based on the IP address of a computer that points to the forward DNS domain name of that computer.

  • Service location (SRV) resource record 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.

You can also add other resource records as needed. For more information, see Checklist: Use Resource Records.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Adding a resource record to a zone

  • Using the Windows interface

  • Using a command line
To add a resource record to a zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Other New Records.

  3. In the Select a resource record type list box, select the type of resource record that you want to add.

  4. Click Create Record.

  5. In New Resource Record, enter the information to complete the resource record.

  6. After you specify all the necessary information for the resource record, click OK to add the new record to the zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To add a resource record to a zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /RecordAdd <ZoneName> <NodeName> [/Aging] [/OpenAcl] [Ttl] <RRType> <RRData>

Parameter Description

dnscmd

The command-line tool for managing DNS servers.

<ServerName>

Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).

/RecordAdd

Required. Adds a new resource record.

<ZoneName>

Required. Specifies the fully qualified domain name (FQDN) of the zone.

<NodeName>

Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.

/Aging

Specifies that this resource record is able to be aged and scavenged. If this command is used, this resource record is able to be aged and scavenged. If this command is not used, the resource record remains in the DNS database unless it is manually updated or removed.

/OpenAcl

Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.

Ttl

Specifies the Time To Live (TTL) setting for the resource record.

<RRType> <RRData>

Required. Specifies the type of resource record to add, followed by the data to be contained in the resource record.

Resource record type | Resource record data
A | IPv4Address
AAAA | Ipv6Address
NS,CNAME,MB,MD,PTR,MF,MG,MR | HostName|DomainName
MX,RT,AFSDB | Preference ServerName
SRV | Priority Weight Port HostName
SOA | PrimSvr Admin Serial#\ Refresh Retry Expire MinTTL
TXT,X25,HINFO,ISDN | String [String]
MINFO,RP | MailboxName ErrMailboxName
WKS | Protocol IPAddress Service...
WINS | MapFlag LookupTimeout CacheTimeout IPAddress...
WINSR | MapFlag LookupTimeout CacheTimeout RstDomainName

<IPAddress>

Specifies a standard IP address, for example, 255.255.255.255.

<ipv6Address>

Specifies a standard IPv6 address, for example, 1:2:3:4:5:6:7:8.

<Protocol>

Specifies the transmission protocol: UDP or TCP.

<Service>

Specifies a standard service, for example, domain, smtp.

<HostName|<DomainName>

Specifies the FQDN of a resource record in the DNS namespace.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /RecordAdd /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Add an Alias (CNAME) Resource Record to a Zone

Alias (CNAME) resource records are also sometimes called canonical name resource records. With these records, you can use more than one name to point to a single host, making it easy to do such things as host both a File Transfer Protocol (FTP) server and a Web server on the same computer. For example, the well-known server names (ftp, www) are registered using alias (CNAME) resource records that map to the Domain Name System (DNS) host name, such as server-1, for the server computer that hosts these services.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Adding an alias (CNAME) resource record to a zone

  • Using the Windows interface

  • Using a command line
To add an alias (CNAME) resource record to a zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable forward lookup zone, and then click New Alias.

  3. In Alias name, type the alias name.

  4. In Fully qualified domain name (FQDN) for target host, type the FQDN of the DNS host computer for which this alias is to be used.

    As an option, you can click Browse to search the DNS namespace for hosts in this domain that have host (A) resource records already defined.

  5. Click OK to add the new record to the zone.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To add an alias (CNAME) resource record to a zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /RecordAdd <ZoneName> <NodeName> [/Aging] [/OpenAcl] [<Ttl>] CNAME <HostName>|<DomainName>

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/RecordAdd | Required. Adds a new resource record.
<ZoneName> | Required. Specifies the name of the zone where this alias (CNAME) resource record will be added.
<NodeName> | Required. Specifies the FQDN of the node in the DNS namespace. You can also type the node name relative to the ZoneName or @, which specifies the zone's root node.
/Aging | Specifies that this resource record is aged and scavenged. If this parameter is not used, the resource record remains in the DNS database unless it is manually updated or removed.
/OpenAcl | Specifies that new records are open to modification by any user. Without this parameter, only administrators may modify the new record.
<Ttl> | Specifies the Time To Live (TTL) setting for the resource record. (The default TTL is defined in the start of authority (SOA) resource record.)
CNAME | Required. Specifies the resource record type of the record that you are adding.
<HostName>|<DomainName> | Required. Specifies the FQDN of any valid DNS host or domain name in the namespace. For FQDNs, a trailing period (.) is used to fully qualify the name.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /RecordAdd /help

Additional considerations

  •
To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.


Modify Security for a Resource Record

You can use this procedure to control who can update or remove a resource record from a zone. For more information, seeSecuring DNS Resource Records.

Membership in the DnsAdmins or the Domain Admins group in Active Directory Domain Services (AD DS), or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To modify security for a resource record

  1. Open DNS Manager.

  2. In the console tree, click the applicable zone.

  3. In the details pane, click the record that you want to view.

  4. On the Action menu, click Properties.

  5. On the Security tab, modify the list of member users or groups that are allowed to securely update the applicable record and reset their permissions as needed.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Secure dynamic updates are only supported or configurable for resource records in zones that are stored in Active Directory Domain Services (AD DS).

  • Security settings that are applied to resource records affect only dynamic updates. These security settings do not affect who may administer the zone where these resource records are located. For information about the security settings that affect who may administer a zone, see "Additional references."

  • Resource records with the same name share the same resource record security settings. The names of resource records are listed in the Name column of DNS Manager.

Additional references

  • Modify Security for a Resource Record

  • Modify Security for a Directory-Integrated Zone

  • Security Information for DNS


Use Aging and Scavenging

Aging and scavenging is the process by which resource records are given a time stamp when they are created and then removed when their age exceeds a specified limit. This process is especially useful for preventing the accumulation of invalid records when resource records are automatically created, as with dynamic update.

  • Understanding Aging and Scavenging

  • Set Aging and Scavenging Properties for a Zone

  • Set Aging and Scavenging Properties for the DNS Server

  • Enable Automatic Scavenging of Stale Resource Records

  • Start Immediate Scavenging of Stale Resource Records

  • View When a Zone Can Start Scavenging Stale Records

  • Reset Aging and Scavenging Properties for a Specified Resource Record


Understanding Aging and Scavenging

The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time.

With dynamic update, resource records are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its own host (A) resource record at startup and is later improperly disconnected from the network, its host (A) resource record might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

If left unmanaged, the presence of stale resource records in zone data may cause some problems:

  • If a large number of stale resource records remain in zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.

  • Domain Name System (DNS) servers that load zones that contain stale resource records might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.

  • The accumulation of stale resource records at the DNS server can degrade its performance and responsiveness.

  • In some cases, the presence of a stale resource record in a zone can prevent a DNS domain name from being used by another computer or host device.

To solve these problems, the DNS Server service has the following features:

  • Time stamping, based on the current date and time that is set at the server computer, for any resource records that are added dynamically to primary-type zones. In addition, time stamps are recorded in standard primary zones where aging and scavenging is enabled.

    For resource records that you add manually, a time-stamp value of zero is used, indicating that these records are not affected by the aging process and that they can remain without limitation in zone data unless you otherwise change their time stamp or delete them.

  • Aging of resource records in local data, based on a specified refresh time period, for any eligible zones.

    Only primary-type zones that are loaded by the DNS Server service are eligible to participate in this process.

  • Scavenging for any resource records that persist beyond the specified refresh period.

    When a DNS server performs a scavenging operation, it can determine that resource records have aged to the point of becoming stale and remove them from zone data. You can configure servers to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.

    For more information, see either Enable Automatic Scavenging of Stale Resource Records or Start Immediate Scavenging of Stale Resource Records.

Caution

By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should be enabled only when all parameters are fully understood. Otherwise, the server can be accidentally configured to delete records that should not be deleted. If a record is accidentally deleted, not only will users fail to resolve queries for that record, but any user can create a record and take ownership of it, even on zones that are configured for secure dynamic update.

A server uses the contents of each resource-record-specific time stamp, along with other aging and scavenging properties that you can adjust or configure, to determine when it scavenges records.

Prerequisites for aging and scavenging

Before you can use the aging and scavenging features of DNS, several conditions must be met:

  1. Scavenging and aging must be enabled, both at the DNS server and on the zone.

    By default, aging and scavenging of resource records is disabled.

  2. Resource records must either be dynamically added to zones or manually modified to be used in aging and scavenging operations.

    Typically, only those resource records that are added dynamically using the DNS dynamic update protocol are subject to aging and scavenging.

    You can, however, enable scavenging for other resource records that are added through nondynamic means. For records that are added to zones in this way, either by loading a text-based zone file from another DNS server or by manually adding them to a zone, a time stamp of zero is set. This makes these records ineligible for use in aging and scavenging operations.

    To change this default, you can administer these records individually, to reset and permit them to use a current (nonzero) time-stamp value. This makes it possible for these records to become aged and scavenged.

    For more information, see Reset Aging and Scavenging Properties for a Specified Resource Record.

Note

In the case of changing a zone from standard primary to Active Directory-integrated, you may want to enable scavenging of all existing resource records in the zone. To enable aging for all existing resource records in a zone, you can use the AgeAllRecords command, which is available through the dnscmd command-line tool.

Aging and scavenging terminology

The following table indicates new or revised terms that have been introduced to help specifically when discussing aging and scavenging.

Term Description

Resource record time stamp

A date and time value that is used by the DNS server to determine removal of the resource record when it performs aging and scavenging operations.

Current server time

The current date and time on the DNS server. This number can be expressed as an exact numeric value at any point in time.

No-refresh interval

An interval of time, determined for each zone, as bounded by the following two events:

  1. The date and time when the record was last refreshed and its time stamp was set.

  2. The date and time when the record next becomes eligible to be refreshed and have its time stamp reset.

This value is needed to decrease the number of write operations to the Active Directory database. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.

Refresh interval

An interval of time, determined for each zone, as bounded by the following two distinct events:

  1. The earliest date and time when the record becomes eligible to be refreshed and have its time stamp reset.

  2. The earliest date and time when the record becomes eligible to be scavenged and removed from the zone database.

This value should be large enough to allow all clients to refresh their records. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.

Start scavenging time

A specific time, expressed as a number. This time is used by the server to determine when a zone becomes available for scavenging.

Scavenging period

When automatic scavenging is enabled at the server, this period represents the time between repetitions of the automated scavenging process. The default value for this is seven days. To prevent deterioration of DNS server performance, the minimum allowed value for this is one hour.

Record refresh

When a DNS dynamic update is processed for a resource record when only the resource record time stamp, and no other characteristics of the record, are revised.

Refreshes generally occur for the following reasons:

  1. When a computer is restarted on the network and, if at startup, its name and IP address information are consistent with the same name and address information it used before being shut down, it sends a refresh to renew its associated resource records for this information.

  2. A periodic refresh is sent by the computer while it is running.

    The Windows DNS Client service renews DNS registration of client resource records every 24 hours. When this dynamic update occurs, if the dynamic update request does not cause modification to the DNS database, it is considered to be a refresh and not a resource record update.

  3. Other network services make refresh attempts, such as: DHCP servers, which renew client address leases; cluster servers, which register and update records for a cluster; and the Net Logon service, which can register and update resource records that are used by Active Directory domain controllers.

Record update

When a DNS dynamic update is processed for a resource record where other characteristics of the record in addition to its time stamp are revised.

Updates generally occur for the following reasons:

  1. When a new computer is added to the network and, at startup, it sends an update to register its resource records for the first time with its configured zone.

  2. When a computer with existing records in the zone has a change in IP address, causing updates to be sent for its revised name-to-address mappings in DNS zone data.

  3. When the Net Logon service registers a new Active Directory domain controller.

Scavenging servers

An optional advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers that are enabled to perform scavenging of the zone.

By default, if this parameter is not specified, all DNS servers that load a directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. In some cases, this parameter can be useful if it is preferable that scavenging only be performed at some servers loading the directory-integrated zone.

To set this parameter, you must specify the list of IP addresses for the servers that are enabled to scavenge the zone in the ZoneResetScavengeServers parameter for the zone. This can be done using the dnscmd command, a command-line based tool for administering Windows DNS servers.

When scavenging can start

After all prerequisites for enabling the use of scavenging are met, it can start for a server zone when the current server time is greater than the value of the start scavenging time for the zone.

The server sets the time value to start scavenging on a per-zone basis whenever one of the following events occurs:

  • Dynamic updates are enabled for the zone.

  • A change in the state of the Scavenge stale resource records check box is applied. You can use DNS Manager to modify this setting at either an applicable DNS server or one of its primary zones.

  • The DNS server loads a primary zone that is enabled to use scavenging.

    This can occur when the server computer is started or when the DNS Server service is started.

  • When a zone resumes service after having been paused.

  • If the zone is AD DS-integrated, replication for the zone must have taken place at least once since the DNS service was restarted or the domain controller was rebooted. When the previous events occur, the DNS server sets the value of start scavenging time by calculating the following sum:

    Current server time + Refresh interval = Start scavenging time

    This value is used as a basis of comparison during scavenging operations.

Example: the aging and scavenging process for a sample record

To understand the process of aging and scavenging at the server, consider the life span and successive stages of a single resource record, as it is added to a server and zone where this process is in effect and then aged and removed from the database.

  1. A sample DNS host, "host-a.example.microsoft.com", registers its host (A) resource record at the DNS server for a zone where aging and scavenging are enabled for use.

  2. When registering the record, the DNS server places a time stamp on this record based on current server time.

    After the record time stamp is written, the DNS server does not accept refreshes for this record for the duration of the zone no-refresh interval. It can, however, accept updates before that time. For example, if the IP address for "host-a.example.microsoft.com" changes, the DNS server can accept the update. In this case, the server also updates (resets) the record time stamp.

  3. Upon expiration of the no-refresh period, the server begins to accept attempts to refresh this record.

    When the initial no-refresh period ends, the refresh period immediately begins for the record. During this time, the server does not suppress attempts to refresh the record for its remaining life span.

  4. During and after the refresh period, if the server receives a refresh for the record, it processes it.

    This resets the time stamp for the record based on the method that is described in step 2.

  5. When subsequent scavenging is performed by the server for the "example.microsoft.com" zone, the record (and all other zone records) are examined by the server.

    Each record is compared to current server time on the basis of the following sum to determine whether the record should be removed:

    Record time stamp + No-refresh interval for zone + Refresh interval for zone

    • If the value of this sum is greater than current server time, no action is taken and the record continues to age in the zone.

    • If the value of this sum is less than current server time, the record is deleted both from any zone data currently loaded in server memory and also from the applicable DnsZone object store in Active Directory Domain Services (AD DS) for the directory-integrated "example.microsoft.com" zone.


Set Aging and Scavenging Properties for a Zone

The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time. You can use this procedure to set the aging and scavenging properties for a specific zone.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Setting aging and scavenging properties for a zone

  • Using the Windows interface

  • Using a command line
To set aging and scavenging properties for a zone using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable zone, and then click Properties.

  3. On the General tab, click Aging.

  4. Select the Scavenge stale resource records check box.

  5. Modify other aging and scavenging properties as needed.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To set aging and scavenging properties for a zone using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config <ZoneName> {/Aging <Value>|/RefreshInterval <Value>|/NoRefreshInterval <Value>}

Parameter | Description
dnscmd | Specifies the name of the command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the Domain Name System (DNS) host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Specifies that the command configures the specified zone.
<ZoneName> | Required. Specifies the name of the zone to which you want to set aging and scavenging.
/Aging | Required. Enables aging for zones.
/RefreshInterval | Required. Specifies the Refresh interval for a scavenging-enabled zone.
/NoRefreshInterval | Required. Specifies the No-refresh interval for a scavenging-enabled zone.
<Value> | Required. For /Aging, type 1 to enable aging. Type 0 to disable aging. For /RefreshInterval, type a value in hours. The default setting is 168 hours (one week). For /NoRefreshInterval, type a value in seconds. The standard setting is 3600 (one hour).

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Aging and Scavenging


Set Aging and Scavenging Properties for the DNS Server

The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time. You can use this procedure to set the default aging and scavenging properties for the zones on a server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Setting aging and scavenging properties for the DNS server

  • Using the Windows interface

  • Using a command line
To set aging and scavenging properties for the DNS server using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable DNS server, and then click Set Aging/Scavenging for all zones.

  3. Select the Scavenge stale resource records check box.

  4. Modify other aging and scavenging properties as needed.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • Aging and scavenging properties that are configured by this procedure act as server defaults that apply only to Active Directory Domain Services (AD DS)–integrated zones. For standard primary zones, you must set the appropriate properties at the applicable zone.

  • When you apply changes for server aging and scavenging settings, DNS Manager prompts you to confirm the changes. You then have the option to apply your changes to new AD DS-integrated zones only. If necessary, you can also apply your changes to existing AD DS-integrated zones.

  • Regardless of whether the Scavenge stale resource records check box is selected as described in step 3, for standard primary zones, this feature is disabled unless it is manually enabled at the applicable zone.

To set aging and scavenging properties for the DNS server using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config {/ScavengingInterval <Value>|/DefaultAgingState <Value>|/DefaultNoRefreshInterval <Value>|/DefaultRefreshInterval <Value>}

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Configures the specified server.
/ScavengingInterval | Required. Sets the frequency by which the server will perform scavenging for all scavenging-enabled zones.
/DefaultAgingState | Required. Sets the default aging configuration for all zones on the server.
/DefaultNoRefreshInterval | Required. Sets the default no-refresh interval for scavenging-enabled zones.
/DefaultRefreshInterval | Sets the default refresh interval for scavenging-enabled zones.
<Value> | For /ScavengingInterval, type a value in hours. The default is 168 (one week). For /DefaultAgingState, type 1 to enable aging for new zones when they are created. Type 0 to disable aging for new zones. For /DefaultNoRefreshInterval, type a value in hours. The default is 168 (one week). For /DefaultRefreshInterval, type a value in hours. The default is 168 (one week).

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Aging and Scavenging


Enable Automatic Scavenging of Stale Resource Records

The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time. You can use this procedure to provide for automatic scavenging of resource records in the zones that are hosted by the Domain Name System (DNS) server.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable automatic scavenging of stale resource records

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable DNS server, and then click Properties.

  3. Click the Advanced tab.

  4. Select the Enable automatic scavenging of stale records check box.

  5. To adjust the Scavenging period, in the drop-down list, select an interval in either hours or days, and then type a number in the text box.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

Additional references

  • Understanding Aging and Scavenging


Start Immediate Scavenging of Stale Resource Records

You can use this procedure to immediately remove server resource records that have exceeded the allotted time since they were created.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Starting immediate scavenging of stale resource records

  • Using the Windows interface

  • Using a command line
To start immediate scavenging of stale resource records using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, right-click the applicable Domain Name System (DNS) server, and then click Scavenge Stale Resource Records.

  3. When you are asked to confirm that you want to scavenge all stale resource records on the server, click OK.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

To start immediate scavenging of stale resource records using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /StartScavenging

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/StartScavenging | Required. Initiates resource record scavenging.

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /StartScavenging /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Aging and Scavenging


View When a Zone Can Start Scavenging Stale Records

You can use this procedure to verify that a zone's scavenging interval is correct.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Viewing when a zone can start scavenging stale records

  • Using the Windows interface

  • Using a command line
To view when a zone can start scavenging stale records using the Windows interface

  1. Open DNS Manager.

  2. On the View menu, click Advanced.

  3. Right-click the applicable zone, and then click Properties.

  4. On the General tab, click Aging.

  5. Under Refresh interval, view when the zone is first eligible to be scavenged for stale resource records.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • The start scavenging date and time stamp are used to determine when zone scavenging starts.

  • After the start scavenging date and time stamp are reached, scavenging can occur only if the Scavenge stale resource records check box is selected. If the check box is cleared, scavenging for the zone cannot be performed.

To view when a zone can start scavenging stale records using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /ZoneInfo <ZoneName> RefreshInterval

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.).
/ZoneInfo | Required. Displays configuration information.
<ZoneName> | Required. Specifies the fully qualified domain name (FQDN) of the zone.
RefreshInterval | Required. Specifies the configuration property that displays when the zone is first eligible to be scavenged for stale resource records. The output value is in hours. The default setting is 168 hours (one week).

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /ZoneInfo /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Aging and Scavenging


Reset Aging and Scavenging Properties for a Specified Resource Record

The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time. You can use this procedure to change how a specific resource record is scavenged.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

Resetting aging and scavenging properties for a specified resource record

  • Using the Windows interface

  • Using a command line
To reset aging and scavenging properties for a specified resource record using the Windows interface

  1. Open DNS Manager.

  2. In the console tree, click the applicable zone.

  3. In the details pane, double-click the resource record for which you want to reset aging and scavenging properties.

  4. Depending on the how the resource record was originally added to the zone, do one of the following:

    • If the record was added dynamically using dynamic update, clear the Delete this record when it becomes stale check box to prevent its aging or potential removal during the scavenging process. If dynamic updates to this record continue to occur, the Domain Name System (DNS) server will always reset this check box so that the dynamically updated record can be deleted.

    • If you added the record statically, select the Delete this record when it becomes stale check box to permit its aging or potential removal during the scavenging process.

Additional considerations

  • To open DNS Manager, click Start, point to Administrative Tools, and then click DNS.

  • This procedure is necessary only for resource records that are dynamically registered. For records that you add to a zone manually, a time stamp value of zero always applies to the record, which excludes it from the scavenging process.

  • Aging and Scavenging properties for name server (NS) resource records and start of authority (SOA) resource records are reset in the properties for the zone, not in the properties of the resource record.

To reset aging and scavenging properties for a specified resource record using a command line

  1. Open a command prompt.

  2. Type the following command, and then press ENTER:

    dnscmd <ServerName> /Config {<ZoneName>|..AllZones} /ScavengingInterval <Value>

Parameter | Description
dnscmd | The command-line tool for managing DNS servers.
<ServerName> | Required. Specifies the DNS host name of the DNS server. You can also type the IP address of the DNS server. To specify the DNS server on the local computer, you can also type a period (.)
/Config | Required. Configures the specified zone.
<ZoneName>|..AllZones | Required. Specifies the fully qualified domain name (FQDN) of the zone. To configure all zones that are hosted on the specified DNS server to allow dynamic updates, type ..AllZones.
/ScavengingInterval | Required. Sets the scavenging interval.
<Value> | Required. The new value for the scavenging interval, specified in hours. The default is 168 (one week).

To view the complete syntax for this command, at a command prompt, type the following command, and then press ENTER:

dnscmd /Config /help

Additional considerations

  • To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.

Additional references

  • Understanding Aging and Scavenging


Managing Clients

Client computers must be configured properly to work with the DNS servers that the clients rely on for resolving network names. You can configure client computers to receive their network addresses from Dynamic Host Configuration Protocol (DHCP) servers, or you can configure them with fixed addresses. You can also configure clients with additional settings to improve their ability to locate network hosts and to be located by them.

  • Understanding DNS Client Settings

  • Enable DNS for DHCP-Enabled Clients

  • Configure DNS for Static Clients


Understanding DNS Client Settings

Domain Name System (DNS) configuration involves the following configuration tasks for TCP/IP properties on each computer:

  • Set a DNS computer or host name for each computer. For example, in the fully qualified domain name (FQDN) wkstn1.widgets.tailspintoys.com., the DNS computer name is the left-most label wkstn1.

  • Set a primary DNS suffix for each computer, which is placed after the computer or host name to form the FQDN. Using the previous example, the primary DNS suffix is widgets.tailspintoys.com.

  • Set a list of DNS servers for clients to use when resolving DNS names, such as a preferred DNS server, and any alternate DNS servers to use if the preferred server is not available.

  • Set the DNS suffix search list or search method to be used by a client when it performs DNS query searches for short, unqualified domain names.

These tasks are discussed in more detail in each of the following sections.

Setting computer names

When you set computer names for DNS, it is useful to think of the name as the left-most portion of an FQDN. For example, in wkstn1.widgets.tailspintoys.com., wkstn1 is the computer name.

You can configure all Windows DNS clients with a computer name based on any of the standard supported characters that are defined in Request for Comments (RFC) 1123, "Requirements for Internet Hosts — Application and Support." These characters include the following:

  • Uppercase letters, A through Z

  • Lowercase letters, a through z

  • Numbers, 0 through 9

  • Hyphens (-)

If you are supporting both NetBIOS and DNS namespaces on your network, you can use a different computer name within each namespace. It is recommended that wherever possible, however, you try to use computer names that are 15 characters or less and that you follow these RFC 1123 naming requirements.

By default, the left-most label in the FQDN for clients equals the NetBIOS computer name, unless this label is 16 or more characters, which is the maximum for NetBIOS names. When the computer name exceeds the maximum length for NetBIOS, the NetBIOS computer name is truncated based on the full label that is specified.

Before you configure computers with varying DNS and NetBIOS names, consider the following implications and their related issues for your deployment:

  • If Windows Internet Name Service (WINS) lookup is enabled for zones that are hosted by your DNS servers, use the same name for both NetBIOS and DNS computer naming. Otherwise, the results of clients attempting to query and resolve the names of these computers will be inconsistent.

If you have an investment in using NetBIOS names to support legacy Microsoft networking technology, we recommend that you revise NetBIOS computer names that are used on your network to prepare for migration to a standard, DNS-only environment. This prepares your network well for long-term growth and interoperability with future naming requirements. For example, if you use the same computer name for both NetBIOS and DNS resolution, consider converting any special characters such as the underscore (_) in your current NetBIOS names that do not comply with DNS naming standards. 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.

Additional considerations

  • Although the use of the underscore (_) in DNS host names or in host (A) resource records has been traditionally prohibited by DNS standards, the use of underscores in service-related names—such as the names that are used for service locator (SRV) resource records—has been proposed to avoid naming collisions in the Internet DNS namespace.

  • In addition to DNS standard naming conventions, Windows Server 2008 DNS supports the use of extended ASCII and Unicode characters. However, because most resolver software written for other platforms (such as UNIX) is based on the Internet DNS standards, this enhanced character support can be used only in private networks with computers running Windows 2000, Windows Server 2003, or Windows Server 2008 DNS.

  • The initial setup of DNS and TCP/IP displays a warning to suggest a standard DNS name if a nonstandard DNS name is entered.

  • By default, computers and servers use DNS to resolve any name that is greater than 15 characters in length. If the name is less than or equal to 15 characters, both NetBIOS and DNS name resolution can be attempted and used to resolve the name.

Setting domain names

The domain name is used with the client computer name to form the FQDN, also known 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, the DNS domain name for a client computer can be the following: If the FQDN, or full computer name, is wkstn1.widgets.tailspintoys.com, the domain name is the widgets.tailspintoys.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 of a component that has a 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 locator (SRV) resource records on a DNS server. For Windows NT Server 4.0 and earlier versions, domain controllers register a DomainName entry in 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 service locator (SRV) resource 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 can also use 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 described in the previous section. In general, acceptable naming conventions for domain names include the use of letters A through Z, numerals 0 through 9, and the hyphen (-). A period (.) in a domain name is always used to separate the discrete parts of a domain name, which are commonly known as labels. Each label corresponds to an additional level that is defined in the DNS namespace tree.

For most computers, the primary DNS suffix that is configured for the computer can be the same as its Active Directory Domain Services (AD DS) domain name, although the two values can also be different.

Important

By default, the primary DNS suffix portion of a computer's FQDN must be the same as the name of the AD DS domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. A domain administrator creates and manages this attribute using Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP).

Configuring a 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 it processes queries and resolves 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 be appropriate for continuous client use under normal conditions.

Additional considerations

  • For computers running Microsoft Windows XP or Windows Vista®, the DNS server list is used by clients only to resolve DNS names. When clients send dynamic updates, for example, 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. For more information, see Understanding Dynamic Update.

  • By default, the DNS client on Windows XP or Windows Vista does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network (VPN) connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or you can modify the registry. For more information, see Windows Server 2003 Resource Kit Registry Reference (http://go.microsoft.com/fwlink/?LinkId=428).

  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone that is named with a single-label name is considered to be a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or you can modify the registry.

  • When DNS clients are configured dynamically using a Dynamic Host Configuration Protocol (DHCP) server, it is possible to have a larger list of provided DNS servers. To provide an IP address list of DNS servers to your DHCP clients, enable option code 6 on the configured options types that is provided by your DHCP server. For Windows Server 2003 and Windows Server 2008 DHCP servers, you can configure a list of up to 25 DNS servers for each client with this option.

  • 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 that is provided to clients.

Configuring a 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 that is configured for network connections.

If no connection-specific suffixes are configured or queries for these resultant connection-specific FQDNs fail, 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 is "widgets.tailspintoys.com", the devolution process is 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 that are made possible 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, which produces a "Name not found" result.

Additional considerations

  • 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. When 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-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, enter a trailing period (.) at the end of the name.

  • Windows Server 2008 supports a specially named zone, called GlobalNames, to provide resolution of a limited set of globally unique, single-label names in an enterprise network. You can use this zone when network requirements make it impractical to use a suffix search list for this purpose. For more information, see Deploying a GlobalNames Zone.

Configuring multiple names

Computers running Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008 are given DNS names by default. Each computer can have its DNS names configured using one of two possible methods:

  • A primary DNS domain name, which applies as the default fully qualified DNS name for the computer and all of its configured network connections

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

Although most computers do not need to support or use more than one name in DNS, support for configuring multiple, connection-specific DNS names is sometimes useful. For example, by using multiple names, a user can specify which network connection to use when connecting to a multihomed computer.

Example: using connection-specific names

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

Multihomed DNS computer configured with many 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 have special needs, such as troubleshooting server networking problems, performing network-based backup, or replicating 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 it is 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 name | IP addresses |  |  | Description
host-a.example.microsoft.com | 10.1.1.11, 10.2.2.22 |  |  | The primary DNS name for computer. The computer registers host (A) and pointer (PTR) resource records for all configured IP addresses under this name in the widgets.tailspintoys.com zone.
host-a.public.example.microsoft.com | 10.1.1.11 |  | The connection-specific DNS name for LAN connection 1, which registers host (A) and pointer (PTR) resource records for IP address 10.1.1.11 in the public.widgets.tailspintoys.com zone.
host-a.backup.example.microsoft.com | 10.2.2.22 | The connection-specific DNS name for LAN connection 2, which registers host (A) and pointer (PTR) resource records for IP address 10.2.2.22 in the backup.widgets.tailspintoys.com zone.

Additional considerations

  • DNS names can be set using remote administration and other remote configuration services, such as DHCP. For a DNS server running Windows Server 2008, the primary DNS domain name can be set using either remote administration or the unattended setup option.

  • For connection-specific naming, you can use TCP/IP configuration methods. You can manually configure the DNS domain name for each connection that appears in the Network Connections folder, or you can use a DHCP option type (option code 15).

  • For more information about DHCP options, see "DHCP Options" in the Networking Collection (http://go.microsoft.com/fwlink/?LinkId=4639).


Enable DNS for DHCP-Enabled Clients

  • To configure Domain Name System (DNS) for clients with dynamically configured IP addresses that are provided by a Dynamic Host Configuration Protocol (DHCP) server, you usually configure the following at either the DHCP server or applicable clients:

    • DNS host name (or names) for the client computer. For DHCP clients, this must be set at the client computer or assigned during unattended setup.

    • Primary and alternate DNS servers that the client uses to assist in resolving DNS domain names. For DHCP clients, this can be set on the DHCP server by assigning the DNS server option (option 6) and providing a configured list of ordered IP addresses for the DNS servers that the client is configured to use.

    • A list of DNS suffixes to be appended for use in completing unqualified DNS names that are used for searching and submitting DNS queries at the client for resolution. For DHCP clients, this can be set on the DHCP server by assigning the DNS domain name option (option 15) and providing a single DNS suffix for the client to append and use in searches. To configure additional DNS suffixes, configure TCP/IP manually for DNS configuration.

    • Connection-specific dynamic update and registration behavior, such as whether specific network adapters that are installed at the client dynamically register their configured IP addresses with a DNS server. For DHCP clients, the default is for client connections to register their configured IP addresses with a DNS server. To modify this behavior at the client, configure TCP/IP manually on the client for DNS configuration.

For more information about how to configure other DNS for DHCP clients, see the applicable TCP/IP or DNS client documentation that is provided by the appropriate vendor.

By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone that is named with a single-label name is considered to be a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or you can modify the registry.

For more information about DHCP options, see "DHCP Options" in the Networking Collection (http://go.microsoft.com/fwlink/?LinkId=4639).

Additional references

  • Understanding DNS Client Settings


Configure DNS for Static Clients

To configure Domain Name System (DNS) for clients with statically configured IP addresses, you usually configure the following:

  • DNS host name (or names) for the client computer.

  • Primary and alternate DNS servers that the client uses to assist in resolving DNS domain names.

  • A list of DNS suffixes to be appended for use in completing unqualified DNS names, which are used for searching and submitting DNS queries at the client for resolution.

  • Connection-specific dynamic update and registration behavior, such as whether specific network adapters that are installed at the client dynamically register their configured IP addresses with a DNS server.

Note

For more information about how to configure DNS for static clients, see the applicable TCP/IP or DNS client documentation that is provided by the appropriate vendor for these clients.

Additional references

  • Understanding DNS Client Settings


Securing DNS

As an open protocol, Domain Name System (DNS) is particularly vulnerable to attackers. Successful attacks can be especially disruptive because of the critical role that DNS plays in most networks. For this reason, it is very important that you to take advantage of the enhanced security features provided for the DNS Server role in Windows Server 2008. This section provides guidance for using these security features.

  • Security Information for DNS

  • Securing DNS Deployment

  • Securing the DNS Server Service

  • Securing DNS zones

  • Securing DNS Resource Records

  • Securing DNS Clients

Additional references

Checklist: Secure Your DNS Server


Security Information for DNS

Domain Name System (DNS) was originally designed as an open protocol. Therefore, it is vulnerable to attackers. Windows Server 2008 DNS helps improve your ability to prevent an attack on your DNS infrastructure through the addition of security features. Before considering which of the security features to use, you should be aware of the common threats to DNS security and the level of DNS security in your organization.

DNS security threats

The following are the typical ways in which your DNS infrastructure can be threatened by attackers:

  • Footprinting: The process by which DNS zone data is obtained by an attacker to provide the attacker with the DNS domain names, computer names, and IP addresses for sensitive network resources. An attacker commonly begins an attack by using this DNS data to diagram, or "footprint," a network. DNS domain and computer names usually indicate the function or location of a domain or computer to help users remember and identify domains and computers more easily. An attacker takes advantage of the same DNS principle to learn the function or location of domains and computers in the network.

  • Denial-of-service attack: An attempt by an attacker to deny the availability of network services by flooding one or more DNS servers in the network with recursive queries. As a DNS server is flooded with queries, its CPU usage eventually reaches its maximum and the DNS Server service becomes unavailable. Without a fully operating DNS server on the network, network services that use DNS become unavailable to network users.

  • Data modification: An attempt by an attacker (that has footprinted a network using DNS) to use valid IP addresses in IP packets the attacker has created, which gives these packets the appearance of coming from a valid IP address in the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IP address range of a subnet), the attacker can gain access to the network and destroy data or conduct other attacks.

  • Redirection: An attacker redirecting queries for DNS names to servers under the control of the attacker. One method of redirection involves the attempt to pollute the DNS cache of a DNS server with erroneous DNS data that may direct future queries to servers under the control of the attacker. For example, if a query is originally made for widgets.tailspintoys.com and a referral answer provides a record for a name outside the tailspintoys.com domain, such as malicious-user.com, the DNS server uses the cached data for malicious-user.com to resolve a query for that name. Attackers can accomplish redirection whenever they have writable access to DNS data, for example, when dynamic updates are not secure.

Mitigating DNS security threats

DNS can be configured to mitigate these common DNS security issues. The following table lists five main areas on which to focus your DNS security efforts.

DNS security area | Description
DNS namespace | Incorporate DNS security into your DNS namespace design. For more information, see Securing DNS Deployment.
DNS Server service | Review the default DNS Server service security settings and apply Active Directory security features when the DNS Server service is running on a domain controller. For more information, see Securing the DNS Server Service.
DNS zones | Review the default DNS zone security settings and apply secure dynamic updates and Active Directory security features when the DNS zone is hosted on a domain controller. For more information, see Securing DNS zones.
DNS resource records | Review the default DNS resource record security settings and apply Active Directory security features when the DNS resource records are hosted on a domain controller. For more information, see Securing DNS Resource Records.
DNS clients | Control the DNS server IP addresses that DNS clients use. For more information, see Securing DNS Clients.

Three levels of DNS security

The following sections describe the three levels of DNS security.

Low-level security

Low-level security is a standard DNS deployment without any security precautions configured. Deploy this level of DNS security only in network environments where there is no concern for the integrity of your DNS data or in a private network where there is no threat of external connectivity. Low-level DNS security has the following characteristics:

  • The DNS infrastructure of the organization is fully exposed to the Internet.

  • Standard DNS resolution is performed by all DNS servers in the network.

  • All DNS servers are configured with root hints pointing to the root servers for the Internet.

  • All DNS servers permit zone transfers to any server.

  • All DNS servers are configured to listen on all of their IP addresses.

  • Cache pollution prevention is disabled on all DNS servers.

  • Dynamic update is allowed for all DNS zones.

  • User Datagram Protocol (UDP) and TCP/IP port 53 is open on the firewall in the network for both source and destination addresses.

Medium-level security

Medium-level security uses the DNS security features that are available without running DNS servers on domain controllers and storing DNS zones in Active Directory Domain Services ( AD DS). Medium-level DNS security has the following characteristics:

  • The DNS infrastructure of the organization has limited exposure to the Internet.

  • All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally.

  • All DNS servers limit zone transfers to servers that are listed in the name server (NS) resource records in their zones.

  • DNS servers are configured to listen on specified IP addresses.

  • Cache pollution prevention is enabled on all DNS servers.

  • Nonsecure dynamic update is not allowed for any DNS zones.

  • Internal DNS servers communicate with external DNS servers through the firewall with a limited list of allowed source and destination addresses.

  • External DNS servers in front of the firewall are configured with root hints that point to the root servers for the Internet.

  • All Internet name resolution is performed using proxy servers and gateways.

High-level security

High-level security uses the same configuration as medium-level security. It also uses the security features that are available when the DNS Server service is running on a domain controller and DNS zones are stored in AD DS. In addition, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required. High-level DNS security has the following characteristics:

  • The DNS infrastructure of the organization has no Internet communication by internal DNS servers.

  • The network uses an internal DNS root and namespace, where all authority for DNS zones is internal.

  • DNS servers that are configured with forwarders use internal DNS server IP addresses only.

  • All DNS servers limit zone transfers to specified IP addresses.

  • DNS servers are configured to listen on specified IP addresses.

  • Cache pollution prevention is enabled on all DNS servers.

  • Internal DNS servers are configured with root hints pointing to the internal DNS servers that host the root zone for the internal namespace.

  • All DNS servers are running on domain controllers. A discretionary access control list (DACL) is configured on the DNS Server service to allow only specific individuals to perform administrative tasks on the DNS server.

  • All DNS zones are stored in AD DS. A DACL is configured to allow only specific individuals to create, delete, or modify DNS zones.

  • DACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data.

  • Secure dynamic update is configured for DNS zones, except the top-level and root zones, which do not allow dynamic updates at all.


Securing DNS Deployment

Securing DNS deployment

When you design your Domain Name System (DNS) server deployment, use the following DNS security guidelines:

  • If your network hosts are not required to resolve names on the Internet, eliminate DNS communication with the Internet.

    In this DNS design, you can use a private DNS namespace that is hosted entirely in your network. The private DNS namespace is distributed just as the Internet DNS namespace, with your internal DNS servers hosting zones for the root domain and top-level domains.

  • Split the DNS namespace for your organization between internal DNS servers behind the firewall and external DNS servers in front of the firewall.

    In this DNS design, your internal DNS namespace is a subdomain of your external DNS namespace. For example, if the Internet DNS namespace for your organization is tailspintoys.com, the internal DNS namespace for your network is corp.tailspintoys.com.

  • Host your internal DNS namespace on internal DNS servers and host your external DNS namespace on external DNS servers that are exposed to the Internet.

    To resolve queries for external names that are made by internal hosts, the internal DNS servers in this DNS design forward queries for external names to the external DNS servers. External hosts use only the external DNS servers for Internet name resolution.

  • Configure your packet-filtering firewall to allow only UDP and TCP port 53 communication between your external DNS server and a single internal DNS server.

    This DNS design facilitates communication between internal and external DNS servers and prevents any other external computer from gaining access to your internal DNS namespace.

For more information, see Security Information for DNS.


Securing the DNS Server Service

To help secure the Domain Name System (DNS) servers in your network, use the following guidelines.

Examine and configure the default DNS Server service settings that affect security

The following configuration options for the DNS Server service have security implications for both the standard and the Active Directory-integrated DNS Server service.

Default setting | Description
Interfaces | By default, a DNS Server service that is running on a multihomed computer is configured to listen for DNS queries using all of its IP addresses. Limit the IP addresses that the DNS Server service listens on to the IP address that its DNS clients use as their preferred DNS server. For more information, see Restrict a DNS server to listen only on selected addresses.
Secure cache against pollution | By default, the DNS Server service is secured from cache pollution, which results when DNS query responses contain nonauthoritative or malicious data. The Secure cache against pollution option helps prevent an attacker from successfully polluting the cache of a DNS server with resource records that were not requested by the DNS server. Changing this default setting reduces the integrity of the responses that are provided by DNS Server service. For more information, see Secure the Server Cache Against Names Pollution.
Disable recursion | By default, recursion is not disabled for the DNS Server service. This makes it possible for the DNS server to perform recursive queries on behalf of its DNS clients and DNS servers that have forwarded DNS client queries to it. Recursion may be used by attackers to deny the DNS Server service. Therefore, if a DNS server in your network is not intended to receive recursive queries, it should be disabled. For more information, see Disable Recursion on the DNS Server
Root hints | If you have an internal DNS root in your DNS infrastructure, configure the root hints of internal DNS servers to point only to the DNS servers that host your root domain, not the DNS servers that host the Internet root domain. This prevents your internal DNS servers from sending private information over the Internet when they resolve names. For more information, see Update Root Hints on the DNS Server and Updating Root Hints.

Manage the DACL on DNS servers running on domain controllers

In addition to the already described default DNS Server service settings that affect security, DNS servers that are configured as domain controllers use a discretionary access control list (DACL). You can use the DACL to control the permissions for the Active Directory users and groups that control the DNS Server service.

The following table lists the default group or user names and permissions for the DNS Server service when it is running on a domain controller.

Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Creator Owner | Special Permissions
DnsAdmins | Allow: Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

When the DNS Server service is running on a domain controller, you can manage its DACL using the Active Directory object MicrosoftDNS. Configuring the DACL on the MicrosoftDNS object has the same effect as configuring the DACL on the DNS server in DNS Manager, which is the recommended method. Consequently, the security administrators of Active Directory objects and DNS servers should be in direct contact to ensure that the administrators do not reverse each other's security settings.

For more information, see Security Information for DNS.


Securing DNS zones

The Domain Name System (DNS) zone configuration options in the following sections have security implications for both standard and Active Directory-integrated DNS zones.

Configure secure dynamic updates

By default, the Dynamic updates setting is not configured to allow dynamic updates. This is the most secure setting because it prevents an attacker from updating DNS zones. However, this setting prevents you from taking advantage of the administrative benefits that dynamic update provides. To configure computers to update DNS data more securely, store DNS zones in Active Directory Domain Services (AD DS) and use the secure dynamic update feature. Secure dynamic update restricts DNS zone updates to only those computers that are authenticated and joined to the Active Directory domain where the DNS server is located and to the specific security settings that are defined in the access control lists (ACLs) for the DNS zone.

For more information, see Allow Only Secure Dynamic Updates.

Manage the DACL on the DNS zones that are stored in AD DS

You can use the discretionary access control list (DACL) to control the permissions for the Active Directory users and groups that may control the DNS zones.

The following table lists the default group or user names and permissions for DNS zones that are stored in AD DS.

Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Authenticated Users | Allow: Create All Child objects
Creator Owner | Special Permissions
DnsAdmins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone | Allow: Read, Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

For more information, see Modify Security for a Directory-Integrated Zone.

The DNS Server service running on a domain controller that has zones stored in AD DS stores its zone data in AD DS using Active Directory objects and attributes. Configuring the DACL on the DNS Active Directory objects has the same effect as configuring the DACL on DNS zones in DNS Manager. Consequently, the security administrators of Active Directory objects and the security administrators of DNS data should be in direct contact to ensure that the administrators do not reverse each other's security settings.

The following table describes the Active Directory objects and attributes that are used by DNS zone data.

Object | Description
DnsZone | This container is created when a zone is stored in AD DS.
DnsNode | This leaf object is used to map and associate a name in the zone to resource data.
DnsRecord | This multivalued attribute of a dnsNode object is used to store the resource records that are associated with the named node object.
DnsProperty | This multivalued attribute of a dnsZone object is used to store zone configuration information.

Restrict zone transfers

By default, the DNS Server service allows zone information to be transferred only to servers that are listed in the name server (NS) resource records of a zone. This is a secure configuration, but for increased security, this setting should be changed to the option that allows zone transfers to specified IP addresses. Changing this setting to allow zone transfers to any server may expose your DNS data to an attacker attempting to footprint your network.

For more information, see Modify Zone Transfer Settings.

Understand the compromise involved in zone delegation

When you are deciding whether to delegate DNS domain names to zones hosted on DNS servers that are administered separately, it is important to consider the security implications of giving multiple individuals the ability to administer the DNS data for your network. DNS zone delegation involves a compromise between the security benefits of having a single authoritative DNS server for all DNS data and the administrative benefits of distributing responsibility for your DNS namespace to separate administrators. This issue is very important when you are delegating the top-level domains of a private DNS namespace, because those domains contain very sensitive DNS data.

For more information, see Understanding Zone Delegation.

Recover DNS zone data

If your DNS data is corrupted, you can restore your DNS zone file from the backup folder, which is located in the %systemroot%/DNS/Backup folder. When a zone is first created, a copy of the zone is added to the backup folder. To recover the zone, copy the original zone file from the backup folder into the %systemroot%/DNS folder. When you use the New Zone Wizard to create the zone, specify the zone file in the %systemroot%/DNS folder as the zone file for the new zone. For more information, see Add a Forward Lookup Zone.

This operation applies only to standard zones that are not stored in AD DS.

For more information, see Security Information for DNS.


Securing DNS Resource Records

The following Domain Name System (DNS) resource record configuration options have security implications for resource records that are stored in both standard DNS zones and Active Directory–integrated DNS zones:

Manage the DACL on DNS resource records that are stored in Active Directory Domain Services

You can use the discretionary access control list (DACL) to control the permissions for the Active Directory users and groups that may control the DNS resource records. For more information, see Modify Security for a Resource Record.

The following table lists the default group or user names and permissions for DNS resource records that are stored in Active Directory Domain Services (AD DS).

Group or user names | Permissions
Administrators | Allow: Read, Write, Create All Child objects, Special Permissions
Authenticated Users | Allow: Create All Child objects
Creator Owner | Special Permissions
DnsAdmins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Domain Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Admins | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects
Enterprise Domain Controllers | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects, Special Permissions
Everyone | Allow: Read, Special Permissions
Pre-Windows 2000 Compatible Access | Allow: Special Permissions
System | Allow: Full Control, Read, Write, Create All Child objects, Delete Child objects

For more information, see Security Information for DNS.


Securing DNS Clients

The following Domain Name System (DNS) client considerations have security implications for DNS clients in a DNS infrastructure.

Whenever possible, specify static IP addresses for the preferred and alternate DNS servers that a DNS client uses

If a DNS client is configured to obtain its DNS server addresses automatically, it obtains them from a Dynamic Host Configuration Protocol (DHCP) server. While this method of obtaining DNS server addresses is secure, it is only as secure as the DHCP server. By configuring DNS clients with static IP addresses for the preferred and alternate DNS servers, you may eliminate one possible avenue of attack.

For more information, see; Enable DNS for DHCP-Enabled Clients.

Control which DNS clients have access to the DNS server

If a DNS server is configured to listen only on specific IP addresses, only DNS clients that are configured to use these IP addresses as preferred and alternate DNS servers will contact the DNS server.

For more information, see Restrict a DNS server to listen only on selected addresses.

For more information, see Security Information for DNS.


Troubleshooting DNS

You can use the information in the following topics to help isolate and solve problems with your Domain Name System (DNS) infrastructure.

  • Troubleshooting DNS Clients

  • Troubleshooting DNS Servers

  • Troubleshooting Dynamic Updates

  • Troubleshooting zone problems


Troubleshooting DNS Clients

What problem are you having?

  • The DNS client received a "Name not found" error message.

  • The DNS client appears to have received a response with stale or incorrect information in it.

  • The DNS client appears to be affected by another problem not described here.

The DNS client received a "Name not found" error message.

Cause: The Domain Name System (DNS) client computer does not have a valid IP configuration for the network.

Solution: Verify that the TCP/IP configuration settings for the client computer are correct, particularly those settings that are used for DNS name resolution.

To verify a client IP configuration, use the ipconfig command. In the command output, verify that the client has a valid IP address, subnet mask, and default gateway for the network where it is attached and being used.

If the client does not have a valid TCP/IP configuration, you can either:

  • For dynamically configured clients, use the ipconfig /renew command to manually force the client to renew its IP address configuration with the Dynamic Host Configuration Protocol (DHCP) server.

  • For statically configured clients, modify the client TCP/IP properties to use valid configuration settings or complete its DNS configuration for the network. Do not configure clients to use both AD DS-integrated DNS servers and Internet Service Provider (ISP) DNS servers. Instead, configure clients only to use AD DS-integrated DNS servers and configure your AD DS-integrated DNS servers to forward queries to your ISP DNS servers.

For more information, see Managing Clients.

Cause: The client was not able to contact a DNS server because of a network-related or hardware-related failure.

Solution: Verify that the client computer has a valid and functioning network connection. First, check that related client hardware (cables and network adapters) are working properly at the client by using basic network and hardware troubleshooting steps.

If the client hardware appears to be prepared and functioning properly, verify that it can contact other computers on the same network by using the ping command.

Cause: The DNS client cannot contact its configured DNS servers.

Solution: If the DNS client has basic connectivity to the network, verify that it can contact a preferred (or alternate) DNS server.

To verify whether a client has basic TCP/IP access to the DNS server, first try contacting the preferred DNS server by its IP address by using the ping command.

For example, if the client uses a preferred DNS server of 10.0.0.1, type ping 10.0.0.1 at the command prompt on the client computer. If you are not sure what the IP address is for the preferred DNS server, you can view it by using the ipconfig command. For example, at the client computer, type ipconfig /all|more if necessary to pause the display so that you can read and note any IP addresses that are listed in DNS servers for the command output.

If no configured DNS servers respond to a direct pinging of their IP address, it indicates that the source of the problem is more likely a network connectivity problem between the client and the DNS servers. If that is the case, follow basic TCP/IP network troubleshooting steps to fix the problem.

Cause: The DNS server is not running or responding to queries.

Solution: If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to listen for and respond to client requests. Try using the nslookup command to test whether the server can respond to DNS clients.

For more information, see Start or Stop a DNS Server.

Cause: The DNS server that the client is using does not have authority for the failed name and cannot locate the authoritative server for this name.

Solution: Confirm whether the DNS domain name that the client is trying to resolve is the DNS domain name for which its configured DNS servers are authoritative.

For example, if the client is attempting to resolve the name host.widgets.tailspintoys.com, verify that the preferred DNS server (or an alternate, if one is being used) that is queried by the client loads the authoritative zone where a host (A) resource record for the failed name should exist.

If the preferred server is authoritative for the failed name and it loads the applicable zone, determine whether the zone is missing the appropriate resource records. If necessary, add the resource records to the zone.

If the preferred server is not authoritative for the failed name, it indicates that configuration errors at the DNS server are the likely cause. As necessary, troubleshoot the problem further at the DNS server.

For more information, see Managing Resource Records and Troubleshooting DNS Servers.

The DNS client appears to have received a response with stale or incorrect information in it.

Cause: The DNS server that the client is using does not have authority for the failed name, and it is using stale information from its local DNS database.

Solution: Determine whether the DNS server is authoritative for the name, and proceed accordingly.

For example, if the client is attempting to resolve the name host.widgets.tailspintoys.com, verify that the preferred DNS server (or an alternate, if one is being used) that is queried by the client loads the authoritative zone where a host (A) resource record for the failed name should exist.

If the preferred server is authoritative for the name and it answered using incorrect data, it indicates that the applicable zone might have outdated or stale information in the applicable resource record data. If that is the case, you can add and remove the appropriate resource record in the zone.

Another option, when dynamic updates are enabled, is to force registration and update at the computer that is targeted by the query. You can force it to update the registration of its resource records by typing the ipconfig /registerdns command at a command prompt.

If the preferred server is not a direct authority for the queried name, it likely answered the query based on information that it obtained and cached during an earlier recursive lookup. In this case, you might consider clearing the server names cache. This compels the server to use new recursive queries for this resource record data and to rebuild its cache contents based on current information.

For more information, see Managing Resource Records and Troubleshooting DNS Servers.

Cause: The preferred DNS server is a secondary server for the zone that contains the targeted name, and it has outdated information.

Solution: If the server that answered the client is a secondary server for the zone, the version of the zone in use at that server might be stale and it may need to be updated more often.

As an immediate solution, you can initiate a zone transfer at the secondary server to its master server to update the zone. You might also consider using any of the following options to improve the freshness of secondary zone data in the future:

  • Specify additional master servers for the secondary server to use when refreshing the zone.

  • Adjust the refresh interval on the zone slightly to decrease the length of time that all authoritative servers for the zone can use the zone before they are required to refresh it.

  • Configure a notify list at a master server that acts as the zone source for the secondary server and enable it to notify this server when the zone changes.

Cause: The name that was queried was specified in error, either through user input or in a stored client configuration.

Solution: Verify that the name was correctly specified in the application where the name query originated.

In most cases, incorrect data in a positive query response indicates one of three possibilities:

  • An incorrect DNS name was entered at the client by a user.

  • A short, unqualified name was used at the client and completed by the local resolver using an unintended DNS suffix.

  • Resource records that are specified in the query were not updated correctly at the DNS server.

Confirm that the name was not entered in error by the user. Verify the exact set of characters that was entered by the user when the original DNS query was made, or check application settings, such as settings for any Internet mail or Web browser configurations that may have been made.

If the name that was used in the initial query was unqualified, and not the fully qualified domain name (FQDN), try using the FQDN instead in the client application and repeating the query. If you do, be sure to include the trailing dot (.) at the end of the name to indicate that the name entered is an exact FQDN.

If the FQDN query succeeds and returns correct data in the response, the most likely cause of the problem is a misconfigured DNS domain suffix search list in the client resolver settings.

If you are using DNS in an environment that does not support dynamic updates or you generally administer zone data manually, you might also want to verify that the resource records involved in answering the query were not entered incorrectly. View them to ensure that the record data that is stored in the zone is correct, or modify it accordingly.

Cause: The primary zone might have missing or errored data

Solution: Verify that the primary server for the zone has complete and accurate data.

The most likely cause for a primary DNS server for a zone to have missing or incomplete data is a failed update request. It is possible that support for dynamic update has not been fully implemented or configured. To resolve the problem, review the DNS dynamic update protocol (Request for Comments (RFC) 2136) and any requirements that it has for DNS servers and clients that use it.

For directory-integrated zones, it is also possible that the affected records for the failed query have been updated in Active Directory Domain Services (AD DS) but not replicated to all DNS servers that are loading the zone. By default, all DNS servers that load zones from AD DS poll it at a set interval (typically every 15 minutes), and they update the zone for any incremental changes to it. In most cases, a DNS update takes no more than 20 minutes to replicate to all DNS servers in an Active Directory domain environment using default replication settings and reliable high-speed links.

If you have specifically configured your zones to disable dynamic update, keep in mind that you must manually add and update most types of resource records that are used in a zone. If this is the case, use DNS Manager to view and update the affected records.

Another possible source for the incorrect data is Windows Internet Name Service (WINS). Determine whether WINS lookup integration is enabled and used with the zone. If you are using WINS lookup with your zones, verify that WINS is not the source of the incorrect data.

For more information, see Troubleshooting Dynamic Updates and Managing Resource Records.

The DNS client appears to be affected by another problem not described here.

Cause: My problem is not described here.

Solution: Search Microsoft TechNet (http://go.microsoft.com/fwlink/?LinkId=170) for the latest technical information that may relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at Microsoft Update (http://go.microsoft.com/fwlink/?LinkId=284).


Troubleshooting DNS Servers

What problem are you having?

  • The DNS server is not responding to clients.

  • The DNS server does not resolve names correctly.

  • The DNS server appears to be affected by a problem for reasons not described here.

The DNS server is not responding to clients.

Cause: The Domain Name System (DNS) server is affected by a network failure.

Solution: Verify that the server computer has a valid functioning network connection. First, check that related client hardware (cables and network adapters) are working properly at the client by using basic network and hardware troubleshooting steps.

If the server hardware appears to be prepared and functioning properly, check that it has network connectivity by using the ping command to contact other computers or routers (such as its default gateway) that are used and available on the same network as the affected DNS servers.

Cause: The DNS server is reachable through basic network testing, but it is not responding to DNS queries from clients.

Solution: If the DNS client can ping the DNS server computer, verify that the DNS server is started and able to listen to and respond to client requests. Try using the nslookup command to test whether the server can respond to DNS clients.

For more information, see Start or Stop a DNS Server.

Cause: The DNS server has been configured to limit service to a specific list of its configured IP addresses. The IP address originally used in testing its responsiveness is not included in this list.

Solution: If the server was previously configured to restrict the IP addresses for which it responds to queries, it is possible that the IP address that are being used by clients to contact it is not in the list of restricted IP addresses that are permitted to provide service to clients.

Try testing the server for a response again, but specify a different IP address that is known to be in the restricted interfaces list for the server. If the DNS server responds for that address, add the missing server IP address to the list.

Cause: The DNS server has been configured to disable the use of its automatically created default reverse lookup zones.

Solution: Verify that automatically created reverse lookup zones have been created for the server or that advanced configuration changes have not been previously made to the server.

By default, DNS servers automatically create the following three standard reverse lookup zones based on Request for Comments (RFC) recommendations.

These zones are created with common IP addresses covered by these zones that are not useful in a reverse lookup search (0.0.0.0, 127.0.0.1, and 255.255.255.255). By being authoritative for the zones corresponding to these addresses, the DNS service avoids unnecessary recursion to root servers to perform reverse lookups on these types of IP addresses.

It is possible, although unlikely, that these automatic zones are not created. This is because disabling the creation of these zones involves advanced manual configuration of the server registry by a user.

To verify that these zones have been created, do the following:

  1. Open DNS Manager.

  2. On the View menu, click Advanced.

  3. In the console tree, click Reverse Lookup Zones.

    Where?

    • DNS/applicable DNS server/Reverse Lookup Zones

  4. In the details pane, verify that the following reverse lookup zones are present:

    • 0.in-addr.arpa

    • 127.in-addr.arpa

    • 255.in-addr.arpa

Cause: The DNS server is configured to use a nondefault service port, for example, in an advanced security or firewall configuration.

Solution: Verify that the DNS server is not using a nonstandard configuration.

This is a rare but possible cause. By default, the nslookup command sends queries to targeted DNS servers using User Datagram Protocol (UDP) port 53. If the DNS server is located on another network and is reachable only through an intermediate host (such as a packet-filtering router or proxy server), the DNS server might use a nonstandard port to listen for and receive client requests.

If this situation applies, determine whether any intermediate firewall or proxy server configuration is intentionally used to block traffic on well-known service ports that are used for DNS. If not, you might be able to add such a packet filter to these configurations to permit traffic to standard DNS ports.

Also, check the DNS server event log to see if Event ID 414 or other critical service-related events have occurred that might indicate why the DNS server is not responding.

The DNS server does not resolve names correctly.

Cause: The DNS server provides incorrect data for queries that it answers successfully.

Solution: Determine the cause of the incorrect data for the DNS server.

Some of the most likely causes include the following:

  • Resource records were not dynamically updated in a zone.

  • An error was made when static resource records were manually added or modified in the zone.

  • Stale resource records in the DNS server database that were left from cached lookups or zone records were not updated with current information or removed when they were no longer needed.

To help prevent the most common types of problems, be sure to first review best practices for tips and suggestions for deploying and managing your DNS servers. Also, follow and use the checklists that are appropriate for installing and configuring DNS servers and clients, based on your deployment needs.

If you are deploying DNS for Active Directory Domain Services (AD DS), note the new directory-integration features. These features can cause some differences for DNS server defaults—when the DNS database is directory-integrated—that differ from the DNS server defaults that are used with traditional file-based storage.

Many DNS server problems start with failed queries at a client. Therefore, it is often a good idea to start there and troubleshoot the DNS client first.

For more information, see Troubleshooting DNS Clients

Cause: The DNS server does not resolve names for computers or services outside your immediate network, for example, the names of computers or services that are located on external networks or the Internet.

Solution: The server has a problem with its ability to correctly perform recursion. Recursion is used in most DNS configurations to resolve names that are not located within the configured DNS domain name that is used by the DNS servers and clients.

If a DNS server fails to resolve a name for which it is not authoritative, the cause is usually a failed recursive query. Recursive queries are used frequently by DNS servers to resolve remote names that are delegated to other DNS zones and servers.

For recursion to work successfully, all DNS servers in the path of a recursive query must be able to respond to and forward correct data. If not, a recursive query can fail for any of the following reasons:

  • The recursive query times out before it can be completed.

  • A remote DNS server fails to respond.

  • A remote DNS server provides incorrect data.

Cause: The DNS server is not configured to use other DNS servers to assist it in resolving queries.

Solution: Check whether the DNS server can use both forwarders and recursion.

By default, all DNS servers are enabled to use recursion, although the option to disable its use is configurable in DNS Manager to modify advanced server options. The other possible situation in which recursion might be disabled is if the server is configured to use forwarders and recursion has been specifically disabled for that configuration.

Note

If you disable recursion on the DNS server, you will not be able to use forwarders on the same server.

For more information, see Configure a DNS Server to Use Forwarders.

Cause: Current root hints for the DNS server are not valid.

Solution: Check whether server root hints are valid.

If they are configured and used correctly, root hints should always point to DNS servers that are authoritative for the zone that contains the domain root and top-level domains.

By default, DNS servers are configured to use root hints that are appropriate to your deployment, based on the following available choices when you use DNS Manager to configure a server:

  1. If the DNS server is installed as the first DNS server for your network, it is configured as a root server.

    For this configuration, root hints are disabled at the server because the server is authoritative for the root zone.

  2. If the installed server is an additional DNS server for your network, you can direct the Configure a DNS Server Wizard to update its root hints from an existing DNS server on the network.

  3. If you do not have other DNS servers on your network but you still need to resolve Internet DNS names, you can use the default root hints file, which includes a list of Internet root servers that are authoritative for the Internet DNS namespace.

Cause: The DNS server does not have network connectivity to the root servers.

Solution: Test for connectivity to the root servers.

If root hints appear to be configured correctly, verify that the DNS server that is used in a failed query can ping its root servers by IP address.

If a ping attempt to one root server fails, it might indicate that an IP address for that root server has changed. Reconfiguration of root servers, however, is uncommon.

A more likely cause is a full loss of network connectivity or in some cases, poor network performance on the intermediate network links between the DNS server and its configured root servers. Follow basic TCP/IP network troubleshooting steps to diagnose connections and determine whether this is the problem.

By default, the DNS service uses a recursive time-out of 15 seconds before failing a recursive query. Under normal network conditions, this time-out does not have to be changed. If performance requires it, however, you can increase this value.

To review additional performance-related information for DNS queries, you can enable and use the DNS server debug log file, Dns.log. This log can provide extensive information about some types of service-related events.

Cause: Other problems exist with updating DNS server data, such as an issue that is related to zones or dynamic updates.

Solution: Determine whether the problem is related to zones. As needed, troubleshoot any issues in this area, such as possible failure of zone transfer.

For more information, see Troubleshooting Dynamic Updates; Troubleshooting zone problems.

The DNS server appears to be affected by a problem for reasons not described here.

Cause: My problem is not described here.

Solution: Search TechNet (http://go.microsoft.com/fwlink/?LinkId=170) for the latest technical information that might relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at Microsoft Update (http://go.microsoft.com/fwlink/?LinkId=284).


Troubleshooting Dynamic Updates

What problem are you having?

  • The DNS client is not performing dynamic updates.

  • The DNS server is not performing dynamic updates.

  • I am having a different problem related to dynamic updates than those described here.

The DNS client is not performing dynamic updates.

Cause: The client, or its Dynamic Host Configuration Protocol (DHCP) server, does not support the use of the Domain Name System (DNS) dynamic update protocol.

Solution: Verify that your clients or servers support the DNS dynamic update protocol.

For client computers to be registered and updated dynamically with a DNS server, either:

  • Install or upgrade client computers to the current version of Windows.

  • Install and use the DHCP Server service on your network to lease client computers.

By default, computers attempt to register and perform dynamic update of their DNS names and IP addresses with a DNS server.

For other types of computers, you can deploy Windows Server 2008 DHCP servers, which can perform proxied registrations and updates as needed for nondynamic clients.

Additional considerations

  • By default, the DNS client on Microsoft Windows XP or Windows Vista does not attempt dynamic update over a Remote Access Service (RAS) or virtual private network (VPN) connection. To modify this configuration, you can modify the advanced TCP/IP settings of the particular network connection or modify the registry. For more information, see the Windows Server 2003 Resource Kit Registry Reference (http://go.microsoft.com/fwlink/?LinkId=428).

  • By default, the DNS client does not attempt dynamic update of top-level domain (TLD) zones. Any zone that is named with a single-label name is considered a TLD zone, for example, com, edu, blank, my-company. To configure the DNS client to allow the dynamic update of TLD zones, you can use the Update Top Level Domain Zones policy setting or you can modify the registry.

Cause: The client was not able to register with the DNS server because of intermittent problems with either the DNS server or the network.

Solution: At the client computer, use the ipconfig command as appropriate to retry registration or renewal and update client information with the DNS server.

You can use the ipconfig /regsiterdns command option to manually force a retry of the client computer's dynamic registration.

For computers running earlier versions of Windows, you can use the options of the ipconfig command to verify, view, or renew the client TCP/IP configuration details as appropriate.

For example, if the client computer obtains its IP address lease from a DHCP server, you might use the ipconfig /renew command to force the client to renew its lease with the DHCP server. This action then causes the DHCP server to submit an update request to its configured DNS server on behalf of the client.

If the DHCP server succeeds in performing the update with the DNS server, the result is an updated DNS host name and updated IP address information for the client computer in the DNS database.

Cause: The client was not able to register and update with the DNS server because of missing or incomplete DNS configuration.

Solution: Verify that the client is fully and correctly configured for DNS, and update its configuration as needed.

One common cause of the client failing to update with the DNS server is that it does not have a DNS suffix (either a primary suffix or connection-specific suffix) configured. This might result in the client attempting to register an incorrect or unintended DNS domain name.

For example, the client might be attempting to register its short or unqualified computer or host name as a top-level domain name in the root zone. This happens because, without a DNS suffix configured for the client computer, it determines the configured short name of a computer (such as host-a) is its fully qualified domain name (FQDN). This occurs only because the computer name does not have a DNS suffix to append to it and qualify the computer name when registering it for the client in DNS.

To update the DNS configuration for a client, either:

  • Configure a primary DNS suffix at the client computer for static TCP/IP clients.

  • Configure a connection-specific DNS suffix for use at one of the installed network connections at the client computer.

For more information, see Managing Clients.

Cause: The DNS client attempted to update its information with the DNS server but failed because of a problem related to the server.

Solution: If a client can reach its preferred and alternate DNS servers as configured, it is likely that the cause of its failed updates can be found elsewhere.

At Windows-based client computers, you can use Event Viewer to check the System log for any event messages that explain why attempts by the client to dynamically update its host (A) or pointer (PTR) resource records failed.

When youi review messages in the System log, filter or order the display of all messages to view the messages that specify DnsApi as the source for the message. Typically, these messages are related to the performance of DNS activities, such as DNS queries or dynamic updates.

A common reason that updates might fail for a mobile client is that the DNS server that is required to accept and perform the update does not respond when the client starts at a remote location on the network. This might be due to network performance issues or it might indicate a problem in the underlying design of your network. Where these issues persist or seem likely, review your DNS deployment and modify it accordingly.

For more information, see Understanding Dynamic Update.

The DNS server is not performing dynamic updates.

Cause: The DNS server does not support dynamic updates.

Solution: Verify that the DNS server that is used by the client can support the DNS dynamic update protocol, as described in RFC 2136.

If you are using other DNS servers on your network, verify that they are running a DNS server implementation that supports dynamic updates.

For more information, see Understanding Dynamic Update.

Cause: The DNS server supports dynamic updates, but it is not configured to accept them.

Solution: Verify that the primary zone where clients require updates is configured to allow dynamic updates.

The default for a new primary zone is to not accept dynamic updates. At the DNS server that loads the applicable primary zone, modify zone properties to allow updates.

For more information, see Allow Dynamic Updates.

Cause: The zone database is not available.

Solution: Verify that the zone is available for update.

First, if necessary, verify that the zone exists. For a standard primary zone, verify that the zone file exists at the server and that the zone is not paused. If you are using Active Directory–integrated zones, verify that the DNS server is running as a domain controller and that it has access to the Active Directory database where zone data is stored.

Secondary zones do not support dynamic updates. If you are trying to determine which server is the primary server for a standard zone, review zone authority records to determine which server is referenced in both the start of authority (SOA) and name server (NS) resource records for the zone. This is the primary server for the zone that can accept dynamic updates to it.

If you need to, you can use DNS Manager to change a secondary zone to become a primary zone so that it can accommodate dynamic updates. However, because standard primary zones use a single-master update model, you can configure only one server to accept dynamic updates for the zone.

If you change the zone type at a secondary server so that it becomes the primary server for that zone, either remove the zone or convert it to another zone type (such as a secondary zone) at the original primary server. Otherwise, zone data becomes inconsistent and causes additional problems.

If you want to have more than one DNS server be able to update a zone, we recommend that you change the zone type so that it becomes Active Directory–integrated. For this zone type to be used, Active Directory Domain Services (AD DS) must be installed and the server computer must be promoted to a domain controller.

After the zone is stored in the directory, other domain controllers can load the zone automatically and they are allowed to update it when they are running the DNS Server service. This is because AD DS supports a multiple (or floating) master update model in which more than one computer can process updates to the directory database.

For more information, see Change the Zone Type; Adding Zones; Understanding Active Directory Domain Services Integration.

Cause: The DNS server is configured to allow only secure dynamic updates, and it has a security-related problem.

Solution: Verify that zone or resource record security does not block or prevent dynamic updates at the server.

Secure update can be enabled for directory-integrated zones and their resource records. If secure dynamic update is in effect for a directory-integrated zone, only users, groups, or computers that have Write permissions may add new resource records to the zone. If secure dynamic update is in effect for resource records, only users, groups, or computers that have Write permissions can update these resource records. Consequently, security might block or prevent a DNS client (or its DHCP server) from performing an update of its host (A) and pointer (PTR) resource records.

In most cases, secure dynamic update does not prevent new records from being created or added to a zone, but it does restrict who is given default permissions to update or modify records. Where necessary, you can use the access control list (ACL) editing features that are available for directory-integrated zones to modify security permissions on a zone or its resource records and enable update by another user, group, or computer.

Typically, this is necessary only if the computer requesting the update is different from the computer that owns the client records and originally created them.

For more information, see Understanding Dynamic Update

Cause: The DNS server that is required to perform the updates is not available on the network.

Solution: Verify that the DNS server is available on the network, or troubleshoot any further issues as necessary.

For more information, see Troubleshooting DNS Servers.

I am having a different problem related to dynamic updates than those described here.

Cause: My problem is not described here.

Solution: Search TechNet (http://go.microsoft.com/fwlink/?LinkId=170) for the latest technical information that might relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at Microsoft Update (http://go.microsoft.com/fwlink/?LinkId=284).


Troubleshooting zone problems

What problem are you having?

  • I am having a problem related to zone transfers.

  • I am trying to use a zone delegation, but it appears to be broken.

  • I am having a different zone problem than the ones described here.

I am having a problem related to zone transfers.

Cause: The DNS Server service is stopped, or the zone is paused.

Solution: Verify that the master (source) and secondary (destination) Domain Name System (DNS) servers that are involved in completing the transfer of the zone are both started and that the zone is not paused at either server.

For more information, see Start or Stop a DNS Server; Pause or Resume a Zone; Understanding Zones.

Cause: The DNS servers that were used during a transfer do not have network connectivity with each other.

Solution: Eliminate the possibility of a basic network connectivity problem between the two servers.

Using the ping command, contact each DNS server by its IP address from its remote counterpart.

For example, at the source server, use the ping command to test IP connectivity with the destination server. At the destination server, repeat the ping test, substituting the IP address for the source server.

Both ping tests should succeed. If they do not succeed, investigate and resolve intermediate network connectivity issues.

Cause: The serial number is the same at both the source and destination servers. Because the value is the same at both servers, no zone transfer occurs between the servers.

Solution: Using DNS Manager, perform the following tasks:

  1. Increase the value of the serial number for the zone at the master server (source) to a number greater than the value at the applicable secondary server (destination).

  2. After you increase the serial number at the master server to a higher value than is used currently at the secondary server, initiate zone transfer at the secondary server.

When you are working in DNS Manager, you can view the zone serial number on the Start of Authority (SOA) tab in the applicable zone properties. To increase this number in the zone, click Increment.

Cause: The master server (source) and its targeted secondary server (destination) are having interoperability-related problems.

Solution: Investigate possible causes for any problems that might be related to interoperability between DNS servers running Windows Server 2008 and other DNS server implementations, such as an older version of the Berkeley Internet Name Domain (BIND) distribution.

Older BIND servers use an uncompressed zone transfer format. By default, servers running Windows Server 2008 (and later version BIND servers) use a faster, compressed format during zone transfers. To accommodate zone transfer with older BIND servers, you must change advanced server options at your DNS servers running Windows Server 2008.

Another possible interoperability issue is the use and inclusion of Windows Internet Name Service (WINS) forward lookup (WINS) resource records in a zone or their counterpart, the WINS reverse lookup (WINS-R) resource record that is used for reverse lookup zones. BIND servers do not recognize these records when the records are included in zone data that is being transferred, and they can flag these records as bad data, possibly failing the zone transfer.

To prevent these records from being used or included in zone transfers to BIND-based servers and other servers that do not recognize them, select the Do not replicate this record option when you configure WINS properties at the applicable zone.

For more information, see Enable DNS to Use WINS Resolution.

Cause: The zone has resource records or other data that cannot be interpreted by the DNS server.

Solution: Verify that the zone does not contain incompatible data, such as unsupported resource records types or data errors.

In most cases, the DNS Server service supports all resource record types that are approved and required for Internet-standard DNS usage.

Also, verify that the server has not been configured in advance to prevent loading a zone when bad data is found and investigate its method for checking names. You can configure these settings with DNS Manager.

Cause: Authoritative zone data is incorrect.

Solution: If a zone transfer continues to fail, ensure that the zone does not contain nonstandard data.

If you edit zone files manually, be aware that records must be formatted and used according to standard record usage and formatting guidelines as specified in the Request for Comments (RFCs) for DNS. In most cases, user input and data errors can be avoided if records are added and managed with DNS Manager.

To determine if incorrect zone data is a likely source for a failed zone transfer, look in the DNS server event log for messages. You can also use the nslookup command with the -ls option to simulate and test a zone transfer, while observing if the data that is returned terminates before full transfer of the zone is complete.

I am trying to use a zone delegation, but it appears to be broken.

Cause: Zone delegations are not configured correctly.

Solution: Review how zone delegations are used, and revise your zone configurations as needed.

Zones contain information about DNS domains and subdomains. For each new zone you create, the zone originally begins as a single-node database for one DNS domain. As necessary, new subdomain nodes can be added directly below the original (parent) domain and stored as a single zone. Sometimes, when new subdomains remain part of the same zone, they are called subzones.

If they are used as subzones, new subdomains are retained as part of the zone and replicated and updated along with the zone as a single entity. You can, however, delegate subdomains away and manage them in their own zones. For each subdomain that is delegated to its own zone, the parent zone must have delegation records added to it.

You can use the New Delegation Wizard in DNS Manager to simplify the addition of these records.

For more information, see Understanding Zone Delegation; Create a Zone Delegation.

I am having a different zone problem than the ones described here.

Cause: My problem is not described above.

Solution: Search TechNet (http://go.microsoft.com/fwlink/?LinkId=170) for the latest technical information that might relate to the problem. If necessary, you can obtain information and instructions that pertain to your problem or issue.

If you are connected to the Internet, the latest operating system updates are available at Microsoft Update (http://go.microsoft.com/fwlink/?LinkId=284).


DNS Tools

There are a number of utilities for administering, monitoring, and troubleshooting both Domain Name System (DNS) servers and clients. These utilities include the following:

  • DNS Manager (DNS on the Administrative Tools menu).

  • Command-line utilities, such as Nslookup, which you can use to troubleshoot DNS problems.

  • Logging features, such as the DNS server log, which you can view by using DNS Manager or Event Viewer. You can also use file-based logs temporarily as an advanced debugging option to log and trace selected service events.

  • Performance-monitoring utilities, such as statistical counters to measure and monitor DNS server activity with System Monitor.

  • Windows Management Instrumentation (WMI), a standard technology for accessing management information in an enterprise environment.

  • Platform Software Developer Kit (SDK).

DNS Manager

The primary tool that you use to manage DNS servers is DNS Manager, the DNS snap-in in Microsoft Management Console (MMC), which appears as DNS in Administrative Tools on the Start menu. You can use DNS Manager along with other snap-ins in MMC, further integrating DNS administration into your total network management. It is also available in Server Manager on computers with the DNS Server role installed.

You can use DNS Manager to perform the following basic administrative server tasks:

  • Performing initial configuration of a new DNS server.

  • Connecting to and managing a local DNS server on the same computer or remote DNS servers on other computers.

  • Adding and removing forward and reverse lookup zones, as necessary.

  • Adding, removing, and updating resource records in zones.

  • Modifying how zones are stored and replicated between servers.

  • Modifying how servers process queries and handle dynamic updates.

  • Modifying security for specific zones or resource records.

In addition, you can also use DNS Manager to perform the following tasks:

  • Perform maintenance on the server. You can start, stop, pause, or resume the server or manually update server data files.

  • Monitor the contents of the server cache and, as necessary, clear it.

  • Tune advanced server options.

  • Configure and perform aging and scavenging of stale resource records that are stored by the server.

In addition, you can also operate DNS Manager from a workstation to remotely administer DNS servers.

Important

You can use DNS Manager only to manage DNS servers running Windows Server operating systems. The console cannot be used to manage other DNS servers, such as BIND servers.

Command-line utilities

There are several command-line utilities that you can use to manage and troubleshoot DNS servers and clients. The following table describes each of these utilities, which you can run either by typing them at a command prompt or by entering them in batch files for scripted use.

Command | Description
Nslookup | Performs query testing of the DNS domain namespace.
Dnscmd | A command-line interface for managing DNS servers. This utility is useful in scripting batch files to help automate routine DNS management tasks or to perform simple unattended setup and configuration of new DNS servers on your network.
Ipconfig | Displays and modifies IP configuration details that are used by the computer. Additional command-line options are included with this utility to provide help in troubleshooting and supporting DNS clients.

Event-monitoring utilities

The Windows Server 2008 family includes two options for monitoring DNS servers:

  • Default logging of DNS server event messages to the DNS server log.

    DNS server event messages are separated and kept in their own system event log, the DNS server log, which you can view using DNS Manager or Event Viewer.

    The DNS server log contains events that are logged by the DNS Server service. For example, when the DNS server starts or stops, a corresponding event message is written to this log. Most additional critical DNS Server service events are also logged here, for example, when the server starts but cannot locate initializing data and zones or boot information stored in the registry or (in some cases) Active Directory Domain Services (AD DS).

    You can use Event Viewer to view and monitor client-related DNS events. These events appear in the System log, and they are written by the DNS Client service at any computers running Windows (all versions).

  • Optional debug options for trace logging to a text file on the DNS server computer.

    You can also use DNS Manager to selectively enable additional debug logging options for temporary trace logging to a text-based file of DNS server activity. The file that is created and used for this feature, Dns.log, is stored in the %systemroot%\System32\Dns folder.

Performance-monitoring utilities

You can do performance monitoring for DNS servers using additional service-specific counters that measure DNS server performance. These counters are accessible through System Monitor, which is provided in the Performance snap-in.

When you use System Monitor, you can create charts and graphs of server performance trends over time for any of your DNS servers. These can be further studied and analyzed to determine if additional server tuning is needed.

Through measurement and review of server metrics over a period of time, it is possible to determine performance benchmarks and decide if further adjustments can be made to optimize the system.

Windows Management Instrumentation

WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components in an enterprise environment. For more information about WMI, see Windows Management Instrumentation (WMI) (http://go.microsoft.com/fwlink/?LinkID=80947).

Platform Software Developer Kit

Computers that run a product in the Windows Server 2008 family provide functions that make it possible for application programmers to use DNS, for example, programmatically making DNS queries, comparing records, and looking up names.

Programmable DNS components are designed for use by C/C++ programmers. Familiarity with networking and DNS is required. Programmers should be familiar with the IP protocol suite, as well as the DNS protocol and DNS operations.


User Interface: DNS Server

  • <DNS Server Name> Properties Sheet

  • <Zone Name> Properties Sheet

  • Advanced Dialog Box (WINS)

  • Mail Exchanger (MX) Resource Record Dialog Box

  • New ATM Address (ATMA) Resource Record Dialog Box

  • New Host Dialog Box

  • New Name Server Record Dialog Box

  • Notify Dialog Box

  • Server Aging/Scavenging Properties Dialog Box

  • Service Location (SRV) Resource Record Dialog Box

  • Zone Aging/Scavenging Properties Dialog Box


<DNS Server Name> Properties Sheet

Item Details

Interfaces

Use this tab to select the IP addresses that the Domain Name System (DNS) server will use to listen for DNS queries.

Forwarders

Use this tab to specify the DNS servers to which this server will refer queries when it cannot resolve them itself. Using forwarders prevents this server from using recursion to resolve DNS queries.

Advanced

Use this tab to perform the following actions:

  • View the server version number.

  • Set advanced server options.

  • Select the type of name checking to be performed for all zones.

  • Select where the server obtains zone data when it starts.

  • Enable and configure default scavenging settings.

Root Hints

Use this tab to specify the servers to be used for root hints when forwarders are not configured or do not respond.

Debug Logging

Use this tab to configure packet-level logging for debugging purposes.

Event Logging

Use this tab to specify the types of events that will be recorded in the DNS event log.

Monitoring

Use this tab to perform tests to verify the correct server configuration.

See Also

  • User Interface: DNS Server


<Zone Name> Properties Sheet

You can use the controls in this properties sheet to administer the properties of a single zone. The following table lists the tabs that can appear in the zone properties sheet, depending on the zone type.

Item Details

General

Use this tab to view the zone's status and to configure the following zone properties:

  • Default aging and scavenging settings

  • Dynamic updates

  • Zone type (including whether the zone data is stored in Active Directory Domain Services (AD DS) or in a file)

  • Replication scope (Active Directory–integrated zones only)

  • Master servers (secondary and stub zones only)

Start of Authority (SOA)

Use this tab to configure the zone's SOA record. The SOA record specifies the following for the zone:

  • Primary server

  • Zone administrator's e-mail address

  • Secondary zone expiration values

  • Minimum default Time To Live (TTL) values for zone resource records

Name Servers

Use this tab to manage the list of authoritative name servers (NS) for the zone.

WINS

Use this tab to enable and manage Windows Internet Name Service (WINS) name resolution for the zone. This tab is not available for stub zones.

Zone Transfers

Use this tab to enable replication of zone data to other servers and to specify which servers can receive zone data. This tab is not available for stub zones.

Security

Use this tab to specify the user accounts that can be used to access the zone and the type of access to be allowed to each account. This tab is available for Active Directory–integrated zones only.

See Also

  • User Interface: DNS Server


Advanced Dialog Box (WINS)

Item | Details
Cache time-out | Provides a space for you to type a Time To Live (TTL) value that can be used by other Domain Name System (DNS) servers and some DNS clients to determine how long they are allowed to cache information in this resource record that is returned through the use of Windows Internet Name Service (WINS) lookup integration. The format of the time that you type should be in days (DDDDD), hours (HH), minutes (MM), and seconds (SS).
Lookup time-out | Provides a space for you to type a length of time to control how long the DNS server waits for a response from WINS before returning a "Name not found" error message to the requester. The format of the time that you type should be in days (DDDDD), hours (HH), minutes (MM), and seconds (SS).

See Also

  • User Interface: DNS Server


Mail Exchanger (MX) Resource Record Dialog Box

Item Details

Host or child domain

The single-part name for a mail exchanger in this zone. If you need to add a name here that contains a period (.) to indicate the name of an additional domain level, first add the additional domain separately in DNS Manager and then add a new mail exchanger (MX) resource record there as a single-part name.

Fully qualified domain name (FQDN)

The domain name to which this resource record applies. The fully qualified domain name (FQDN) uniquely identifies the DNS hierarchical tree by specifying a list of names that are separated by dots in the path from the referenced domain or host to the root.

Fully qualified domain name (FQDN) of mail server

An FQDN for a host that is willing to act as a mail exchanger for the owner that is specified in Host or child domain. This can be any name that DNS recognizes as a full and valid name for a host computer that runs a mail server. The name that you type here must resolve to a corresponding host (A) resource record in this zone. If you are unsure of which FQDN to use, click Browse to search the DNS namespace for this name.

Mail server priority

A number between 0 and 65535 that indicates the mail exchange server’s priority with respect to the other mail exchange servers. Lower numbers are given preference to servers that are referenced in mail exchanger (MX) resource records with higher priority numbers. The highest priority or preference for a mail exchange server is granted when a value of zero (0) is used.

Where more than one mail exchanger (MX) resource record is present, the mailer attempts delivery to the mail exchange server with the lowest preference number first. If delivery fails, the mail exchange server with the next highest preference number is tried.

If two or more mail exchange servers share the same preference number, the mailer tries the mail exchange servers with the same number at random.

See Also

  • User Interface: DNS Server


New ATM Address (ATMA) Resource Record Dialog Box

Item | Details
Host (uses parent domain if left blank) | The single-part name for an asynchronous transfer mode (ATM) host in this zone. If you need to add a name here that contains a period (.) to indicate the name of an additional domain level, first add the additional domain separately in DNS Manager and then add a new ATM address (ATMA) record there as a single-part name.
Fully qualified domain name (FQDN) | The domain name to which this resource record applies. The FQDN uniquely identifies the DNS hierarchical tree by specifying a list of names that are separated by dots in the path from the referenced domain or host to the root.
Format | E164 specifies that your ATM host uses the E.164 address format for ATM addresses. NSAP specifies that your ATM host uses addresses that conform to the Network Service Access Protocol (NSAP) address model for ATM addresses.
Value | The ATM address (ATMA) of the ATM host in your network.

See Also

  • User Interface: DNS Server


New Host Dialog Box

Item | Details
Name (uses parent domain name if blank) | The single-part name for a host (a computer or other device) in this zone. If this box is blank, the host name is the same as the parent domain name. If you need to add a name here that contains a period (.) to indicate the name of an additional domain level, first add the additional domain separately in DNS Manager and then add a new host record there as a single-part name.
Fully qualified domain name (FQDN) | The domain name to which this resource record applies. The FQDN uniquely identifies the DNS hierarchical tree by specifying a list of names that are separated by dots in the path from the referenced domain or host to the root.
IP address | Provides a space for you to type the IP address for the host that you specify in Name. The DNS server does not attempt to verify the existence of the host that is represented by this IP address. If you supply an Internet Protocol version 4 (IPv4) address, the DNS server creates a host (A) resource record. If you supply an Internet Protocol version 6 (IPv6) address, the DNS server creates an IPv6 host (AAAA) resource record.
Create associated pointer (PTR) record | Creates a resource record in the reverse lookup zone. A pointer (PTR) resource record maps a reverse DNS domain name based on the IP address of a computer that points to the forward DNS domain name of that computer.
Allow any authenticated user to update DNS records with the same owner name | When this option is selected, it permits the resource record to be updated dynamically. When the update is performed, the host that requests the update is granted permission to modify the resource record, but all other nonadministrative permissions are removed from the access control list (ACL) that protects the resource record. This makes it possible for the administrator to create a secure resource record for a host that is not yet online and still enable the resource record to be updated dynamically when the host obtains its IP address through Dynamic Host Configuration Protocol (DHCP).

See Also

  • User Interface: DNS Server


New Name Server Record Dialog Box

Item | Details
Resolve | Resolves the fully qualified domain name (FQDN) of the specified server computer to its IP address, verifies that the server is a name server, and adds it to the IP address list.
IP Addresses of this NS Record | Lists the IP addresses that the new name server will use to respond to Domain Name System (DNS) queries. To add an address, click somewhere in the list, and then type the address.
Delete | Removes the selected IP address from the list of name servers.
Up Down | Moves the selected IP address up or down in the list.

See Also

  • User Interface: DNS Server


Notify Dialog Box

Item | Details
Automatically notify | When this option is selected, it specifies that the indicated secondary servers are to be notified of zone updates.
Servers listed on the Name Servers tab | When this option is selected, it specifies that all secondary servers are to be notified of zone updates.
The following servers | When this option is selected, it lists the secondary servers that are notified of zone updates. To add a server to the list, click the list, type the IP address or Domain Name System (DNS) name of the server, and then click the list again to resolve and verify the server.

See Also

  • User Interface: DNS Server


Server Aging/Scavenging Properties Dialog Box

When you configure the following settings for server properties, the settings apply as the default value for all zones. When they are configured at a specific zone, the settings apply only to that zone.

Item Details

Scavenge stale resource records

Specifies whether stale resource records should be removed from the Domain Name System (DNS) database.

No-refresh interval

Specifies an interval of time in either days or hours. When a resource record is refreshed, it is not refreshed again until this interval of time has elapsed.

Refresh

Specifies the minimum time that resource records are expected to remain in the DNS database after the no-refresh interval expires.

This interval should not be smaller than the maximum refresh period for any resource records. In most networks, this interval corresponds to the Dynamic Host Configuration Protocol (DHCP) lease renew interval. For DHCP servers running Windows Server, the default renew interval is four days.

See Also

  • User Interface: DNS Server


Service Location (SRV) Resource Record Dialog Box

Item Details

Domain

The fully qualified domain name (FQDN) for the domain to which this resource record applies.

Service

The universal symbolic name of the TCP/IP service, such as "_telnet" or "_smtp" to be served by this record.

Protocol

The transport protocol that is used by this service. In most cases, this value is either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), although other transport protocols can be used if they are implemented for your network.

Priority

A number between 0 and 65535 that indicates the priority or level of preference given for this record to the host that is specified in Host offering this service.

Priority indicates this host’s priority with respect to the other hosts in this domain that offer the same service and are specified by different service location (SRV) resource records. Lower numbers are given higher preference. The highest priority or preference goes to a host (offering the service that is specified in this record) that has a priority value of zero (0).

Where more than one service location (SRV) resource record is present for a specific service, the host with the lowest preference number is given first to Domain Name System (DNS) clients. If this host fails or is not reachable, the SRV-specified host with the next highest preference number is the next host that is used.

If two or more hosts that are listed in the service location (SRV) resource record for a specified service share the same preference number, DNS clients can try hosts of equal preference in random order.

Weight

A number between 1 and 65535 to be used as a load-balancing mechanism. When you select among more than one target SRV host for the type of service (specified in Service) that use the same Priority number, you can use this field to weight preference toward specific hosts. Where several hosts share equal priority, SRV-specified hosts with higher weight values that are entered here should be returned first to resolver clients in SRV query results.

We recommend that you use a value of 0 (no weighting) when load-balancing is not needed. This reduces processing time for SRV queries and makes SRV resource records more readable.

Port number

The TCP/IP server port on the host that offers the service that is specified in Service on the target host that is specified in Host offering this service. The range of port numbers is 0 through 65535. This number is often—but not required to be—a well-known reserved port number as specified in Requests for Comments (RFC) 1700, "Assigned Numbers." Depending on the value in Protocol that is included in this record, the port number can represent either a UDP or TCP port.

Host offering this service

The FQDN of the target host that provides the type of TCP/IP-based service that is described in Service. This name must match a valid host (A) resource record in the DNS domain namespace. If a target FQDN consisting of a single period (".") is used here, it indicates to any DNS resolvers (clients) requesting this type of service that this service is not available for this domain.

Allow any authenticated user to update all DNS records with the same name. This setting applies only to DNS records for a new name.

When this option is selected, it permits the resource record to be updated dynamically. When the update is performed, the host requesting the update is granted permission to modify the resource record, but all other nonadministrative permissions are removed from the access control list (ACL) that protects the resource record. This makes it possible for the administrator to create a secure resource record for a host that is not yet online and still enable the resource record to be updated dynamically when the host obtains its IP address through Dynamic Host Configuration Protocol (DHCP).

See Also

  • User Interface: DNS Server


Zone Aging/Scavenging Properties Dialog Box

When you configure the following settings for server properties, the settings apply as the default value for all zones. When you configure these settings at a specific zone, the settings apply only to that zone.

Item Details

Scavenge stale resource records

Specifies whether stale resource records should be removed from the Domain Name System (DNS) database.

No-refresh interval

Specifies an interval of time, in either days or hours. When a resource record is refreshed, it is not refreshed again until this interval of time has elapsed.

Refresh

Specifies the minimum time that records are expected to remain in the DNS database after the no-refresh interval expires.

This interval should not be smaller than the maximum refresh period for any resource records. In most networks, this interval corresponds to the Dynamic Host Configuration Protocol (DHCP) lease renewal interval. For DHCP servers running Windows Server 2008, the default lease renew interval is four days.

See Also

  • User Interface: DNS Server