The DNS service allows a DNS namespace to be divided up into zones that store name information about one or more DNS domains. The zone becomes the authoritative source for information about each DNS domain name included in a zone. This lesson introduces you to DNS zones and how they are configured.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
The DNS service 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. The DNS namespace represents the logical structure of your network resources, and DNS zones provide physical storage for these resources.
When deciding whether or not to divide your DNS namespace to make additional zones, your answers to the following questions will help you determine whether or not to use additional zones:
If you can answer "yes" to one of these questions, it may be useful to add or restructure your namespace into additional zones. When choosing how to structure zones, you should use a plan that meets the needs of your organization.
There are two zone lookup types: forward lookup zones and reverse lookup zones.
A forward lookup zone enables forward lookup queries. On name servers, you must configure at least one forward lookup zone for the DNS service to work. When you install Active Directory using the Active Directory Installation wizard and allow the wizard to install and configure your DNS server, the wizard automatically creates a forward lookup zone based on the DNS name you specified for the server.
There are three types of zones that you can configure:
For networks deploying DNS to support Active Directory, directory-integrated primary zones are strongly recommended and provide multimaster update and enhanced security, automatic zone replication and synchronization, simplified planning, and faster directory replication.
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 conducted based on a multimaster update model. In this model, any authoritative DNS server (such as a domain controller running the DNS service) is designated as a primary source for the zone. Because the master copy of the zone is maintained in the Active Directory database, which is fully replicated to all domain controllers, the zone can be updated by the DNS service at any domain controller in the domain. With the multimaster update model of Active Directory, 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 using directory-integrated zones, you can use access control list (ACL) editing to provide granulated access to either the zone or a specified resource record in the zone. For example, an ACL for a specific domain name in the zone can be restricted so that dynamic updates are only allowed for specified DNS clients or to authorize only a secure group such as domain administrators with permissions for updating zone or record properties for it. This security feature is not available with standard primary zones.
Although DNS service can be selectively removed from a domain controller, directory-integrated zones are already stored at each domain controller, so zone storage and management are not additional resources. Also, the methods used to synchronize directory-stored information offer performance improvement over standard zone update methods, which can potentially require transfer of the entire zone.
When namespaces are stored and replicated separately (for example, one for DNS storage and replication and another for Active Directory), an additional administrative complexity is added to planning and designing your network and allowing for its eventual growth. By integrating DNS storage, you can unify managing of storage and replication for both DNS and Active Directory information as a single administrative entity.
Because Active Directory replication processing is performed on a per-property basis, only relevant changes are propagated. This allows less data to be used and submitted in updates for directory-stored zones.
Typically, a zone is named after the highest domain in the hierarchy that the zone encompasses—that is, the root domain for the zone. For example, for a zone that encompasses both microsoft.com and sales.microsoft.com, the zone name would be microsoft.com.
For the standard primary forward lookup zone type you must specify a zone file. The zone file is the zone database file name, which defaults to the zone name with a .dns extension. For example, if your zone name is microsoft.com, the default zone database file name is MICROSOFT.COM.DNS.
When migrating a zone from another server, you can import the existing zone file. You must place the existing file in the systemroot\System32\DNS directory on the target computer before creating the new zone, where systemroot indicates the Windows 2000 installation folder, typically C:\Winnt.
For the standard secondary forward lookup zone type you must specify the DNS server(s) from which you want to copy the zone. You must enter the Internet Protocol (IP) address of one or more DNS servers.
A reverse lookup zone enables reverse lookup queries. Reverse lookup zones are not required by DNS servers in order to provide functionality. However, a reverse lookup zone is required to run troubleshooting tools, such as NSLOOKUP, and to record a name instead of an IP address in Internet Information Services (IIS) log files.
Resource records are entries in the zone database file that associate DNS domain names to related data for a given network resource, such as an IP address. There are many different types of resource records. When a zone is created, DNS automatically adds two resource records: the Start of Authority (SOA) and the Name Server (NS) records. Table 18.1 describes these resource record types, along with the other frequently used resource records.
Table 18.1 Frequently Used Resource Record Types
|Resource record type||Description|
|Host (A)||Lists the host name-to-IP-address mappings for a forward lookup zone.|
|Alias (CNAME)||Creates an alias, or alternate name, for the specified host name. You can use a Canonical Name (CNAME) record to use more than one name to point to a single IP address. For example, you can host a File Transfer Protocol (FTP) server, such as ftp.microsoft.com, and a Web server, such as www.microsoft.com, on the same computer.|
|Host Information (HINFO)||Identifies the central processing unit (CPU) and operating system used by the host. Use this record as a low-cost resource-tracking tool.|
|Mail Exchanger (MX)||Identifies which mail exchanger to contact for a specified domain and in what order to use each mail host.|
|Name Server (NS)||Lists the name servers that are assigned to a particular domain.|
|Pointer (PTR)||Points to another part of the domain namespace. For example, in a reverse lookup zone, it lists the IP-address-to-name mapping.|
|Service (SRV)||Identifies which servers are hosting a particular service. For example, if a client needs to find a server to validate logon requests, the client can send a query to the DNS server to obtain a list of domain controllers and their associated IP addresses.|
|Start of Authority (SOA)||Identifies which name server is the authoritative source of information for data within this domain. The first record in the zone database file must be the SOA record.|
For more information on resource records, use your Web browser to search for RFC 1035, RFC 1183, RFC 1886, and RFC 2052 to retrieve the contents of these Requests for Comment (RFCs).
Follow these steps to view a resource record:
To add a resource record, right-click the zone to which you want to add the record, and then select the type of record that you want to add, for example New Host or New Mail Exchanger.
A zone starts as a storage database for a single DNS domain name. If other domains are added below the domain used to create the zone, these domains can either be part of the same zone or part of another zone. Once a subdomain is added, it can then be
For example, Figure 18.1 shows the microsoft.com domain, which contains domain names for Microsoft. When the microsoft.com domain is first created at a single server, it is configured as a single zone for all of the Microsoft DNS namespace. If, however, the microsoft.com domain needs to use subdomains, those subdomains must be included in the zone or delegated away to another zone. In Figure 18.1, the example subdomain was added to the microsoft.com domain. The example.microsoft.com zone was created to support the example.microsoft.com subdomain.
Figure 18.1 Delegating a new subdomain to a new zone
When you delegate zones within a namespace, you must also create SOA resource records to point to the authoritative DNS server 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 being made authoritative for the new zone. The New Delegation wizard is available to assist in delegation of zones.
All domains (or subdomains) that appear as part of the applicable zone delegation must be created in the current zone prior to performing delegation.
In this lesson you learned that the DNS service 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. The DNS namespace represents the logical structure of your network resources, and DNS zones provide physical storage for these resources.
You also learned how to configure forward and reverse lookup zones and that directory-integrated primary zones are strongly recommended and provide the following benefits: multimaster update and enhanced security, automatic zone replication when new domain controllers are added, simplified administration with integrated namespace storage, and faster replication.
Finally, you learned how to add resource records and delegate zones when new subdomains are added.