Lesson 1: Understanding DNS

DNS is most commonly associated with the Internet. However, private networks use DNS extensively to resolve computer names and to locate computers within their local networks and the Internet. DNS provides the following benefits:

• DNS names are user-friendly, which means that they are easier to remember than IP addresses.
• DNS names remain more constant than IP addresses. An IP address for a server can change, but the server name remains the same.
• DNS allows users to connect to local servers by using the same naming convention as the Internet.

The domain name space is the naming scheme that provides the hierarchical structure for the DNS database. Each node represents a partition of the DNS database. These nodes are referred to as domains.

The DNS database is indexed by name; therefore, each domain must have a name. As you add domains to the hierarchy, the name of the parent domain is appended to its child domain (called a subdomain). Consequently, a domain's name identifies its position in the hierarchy. For example, in Figure 3.1, the sales.microsoft.com domain name identifies the sales domain as a subdomain of the microsoft.com domain and microsoft as a subdomain of the com domain.

The hierarchical structure of the domain name space consists of a root domain, top-level domains, second-level domains, any subdomains, and host names.

Figure 3.1 Hierarchical structure of a domain name space

The root domain is at the top of the hierarchy and is represented as a period (.). The Internet root domain is managed by several organizations, including Network Solutions, Inc.

Top-level domains are two or three-character name codes. Top-level domains are organized by organization type or geographic location. Table 3.1 provides some examples of top-level domain names.

Table 3.1 Top-Level Domains

Top-level domain	Description
gov	Government organizations
com	Commercial organizations
edu	Educational institutions
org	Noncommercial organizations
au	Country code of Australia

Top-level domains can contain second-level domains and host names.

Organizations, such as Network Solutions, Inc., assign and register second-level domains to individuals and organizations for the Internet. A second-level name has two name parts: a top-level name and a unique second-level name. Table 3.2 provides some examples of second-level domains.

Table 3.2 Second-Level Domain Examples

Second-level domain	Description
ed.gov	United States Department of Education
microsoft.com	Microsoft Corporation
stanford.edu	Stanford University
w3.org	World Wide Web Consortium
pm.gov.au	Prime Minister of Australia

Organizations can create additional names that extend their DNS tree to represent departments, divisions, or other geographic locations. Subdomains have three name parts: a top-level name, a unique second-level name, and a unique name representing the department or location—for example, sales.microsoft.com.

Host names refer to specific computers on the Internet or a private network. For example, in Figure 3.1, Computer1 is a host name. A host name is the leftmost portion of a fully qualified domain name (FQDN), which describes the exact position of a host within the domain hierarchy. Computer1.sales.microsoft.com. (including the end period, which represents the root domain) is an FQDN (see Figure 3.1).

DNS uses a host's FQDN to resolve a name to an IP address. The host name does not have to be the same as the computer name. By default, TCP/IP setup uses the computer name for the host name, replacing illegal characters, such as the underscore (_), with a hyphen (-).

When you create a domain name space, consider the following domain guidelines and standard naming conventions:

• Limit the number of domain levels. Typically, DNS host entries should be three or four levels down the DNS hierarchy and no more than five levels down the hierarchy. The numbers of levels increase the administrative tasks.
• Use unique names. Each subdomain must have a unique name within its parent domain to ensure that the name is unique throughout the DNS name space.
• Use simple names. Simple and precise domain names are easier for users to remember and enable users to search intuitively and locate Web sites or other computers on the Internet or an intranet.
• Avoid lengthy domain names. Domain names can be up to 63 characters, including the periods. The total length of an FQDN cannot exceed 255 characters. Case-sensitive naming is not supported.
• Use standard DNS characters and Unicode characters.

• Windows 2000 supports the following standard DNS characters: A-Z, a-z, 0-9, and the hyphen (-), as defined in RFC 1035.
• The DNS Service also supports the Unicode character set. The Unicode character set includes additional characters not found in the American Standard Code for Information Interchange (ASCII) character set, that are required for languages such as French, German, and Spanish.

A zone represents a discrete portion of the domain name space. Zones provide a way to partition the domain name space into manageable sections.

• Multiple zones in a domain name space are used to distribute administrative tasks to different groups. For example, Figure 3.2 depicts the microsoft.com domain name space divided into two zones. The two zones allow one administrator to manage the microsoft and sales domains and another administrator to manage the development domain.
• A zone must encompass a contiguous domain name space. For example in Figure 3.2, you could not create a zone that consists of only the sales.microsoft.com and development.microsoft.com domains, because these two domains are not contiguous.

Figure 3.2 Domain name space divided into zones

The name-to-IP address mappings for a zone are stored in the zone database file. Each zone is anchored to a specific domain, referred to as the zone's root domain. The zone database file does not necessarily contain information for all subdomains of the zone's root domain, only those subdomains within the zone.

In Figure 3.2, the root domain for Zone1 is microsoft.com, and its zone file contains the name-to-IP-address mappings for the microsoft and sales domains. The root domain for Zone2 is development, and its zone file contains the name-to-IP-address mappings for the development domain only. The zone file for Zone1 does not contain the name-to-IP-address mappings for the development domain, although development is a subdomain of the microsoft domain.

A DNS name server stores the zone database file. Name servers can store data for one zone or multiple zones. A name server is said to have authority for the domain name space that the zone encompasses.

One name server contains the master zone database file, referred to as the primary zone database file, for the specified zone. As a result, there must be at least one name server for a zone. Changes to a zone, such as adding domains or hosts, are performed on the server that contains the primary zone database file.

Multiple name servers act as a backup to the name server containing the primary zone database file. Multiple name servers do the following:

• Perform zone transfers. The additional name servers obtain a copy of the zone database file from the name server that contains the primary database zone file. This is called a zone transfer. These name servers periodically query the name server containing the primary zone database file for updated zone data.

• Provide redundancy. If the name server containing the primary zone database file fails, the additional name servers can provide service.
• Improve access speed for remote locations. If there are a number of clients in remote locations, use additional name servers to reduce query traffic across slow wide area network (WAN) links.
• Reduce the load on the name server containing the primary zone database file.

Zone transfer is the process of replicating a zone file to multiple name servers, and is achieved by copying the zone file information from the master server to the secondary server. The master server is the source of the zone information, and can be either a primary or secondary server. The zone transfer process is initiated when one of the following occurs:

• The master server sends a notification of a change in the zone to the secondary server or servers.
• The secondary server queries the primary server for changes to the zone file. This occurs when the DNS Server Service on the secondary server starts, or the secondary server's refresh interval has expired. The refresh interval in the SOA (Start of Authority) resource record is set to 15 minutes by default.

There are two methods used for zone replication.

• Full zone transfer (AXFR) replicates the entire zone file. AXFR zone update is used and supported by most DNS implementations. When the refresh interval elapses on a secondary server, it queries its zone master server using an AXFR query. The secondary server detects whether its local copy of a zone is current to its zone master source by comparing serial numbers for the zone. If the secondary server detects that its copy of the zone database file is not current, it pulls the entire contents of the zone database file from the master server.

• Incremental zone transfer (IXFR), replicates only changes to the zone file. IXFR zone update is new to the Windows 2000 DNS Server Service, and can reduce the amount of zone data that is transferred to fully update a zone. IXFR allows the transfer of only records that have been changed or added, rather than transferring the entire zone file. Changes and additions are kept in a cache at the primary server and are transferred to a requesting DNS secondary server if it is determined that the secondary server does not have the updated information. Synchronization is kept through the use of serial numbers for each zone file.

How often zone transfers should occur is a function of how often names and IP address mappings change within your domain. Unnecessary zone transfers could cause excessive network and server loads.

You configure primary and secondary zones with the information necessary to initiate and request zone transfers by using the State Of Authority (SOA) tab of the zone's Properties dialog box and the Notify dialog box (via the Zone Transfers tab). You can change the default zone transfer timers by using the State Of Authority (SOA) tab. You can also change the following values that affect zone transfer:

• Serial Number. Identifies changes in a zone. Normally, the serial number does not need to be modified and it is automatically incremented on a primary server each time a zone is changed. In some instances, however, setting a larger serial number for a primary zone can be useful to force all secondary zone servers to update zone data.
• Refresh Interval. Controls how often a secondary server will poll a primary server for new data. The default setting is 15 minutes. A smaller value can be used where high-speed network links are used between a primary zone server and secondary servers. This value can also be increased where network connection speeds are slower, or connections are only started on demand.
• Retry Interval. Controls how often retries occur. A retry interval is the length of time that a secondary server should wait before retrying a refresh if a primary server is offline. Normally, this value is set to some fraction of the refresh interval. The default is 10 minutes.
• Expire Interval. Controls the length of time that a secondary server will use its current zone data to answer queries if the server fails to contact the primary zone server. After the length of the expire time has been reached by a secondary with no further contact to the primary server, the secondary will cease to provide name service. Therefore, this value should be set to a length that is greater than the length of time used by a major server outage. The default is 24 hours, but larger values are commonly used for many installations.
• Minimum (default) TTL. Applies by default to all resource records in the zone and determines how long names returned by a zone's name servers will be cached on other name servers that receive this data. The minimum Time to Live (TTL) value affects name caching performance throughout all servers in a zone. This value can be increased to a value of one to five days where zone changes are infrequent, and temporarily decreased during periods when major updates or revisions to a zone are being made. The default for this value is 60 minutes.

DNS Notify is a revision to DNS that requests that the source server for a zone notify certain secondary servers in that zone of changes to the zone file. The secondary servers can then check to see whether they need to initiate a zone transfer. This process can help improve the consistency of zone data among secondary servers.

The following list describes the order in which the DNS Notify process works:

1. The local zone file on a primary server is updated. When the updated zone file is written to the hard disk, the serial number field in the SOA resource record is updated to indicate that the zone file has been updated.
2. The primary server then sends a notify message to other name servers that are part of a notify set.
3. All secondary name servers that receive the notify message respond by initiating an SOA type query back to the notifying server (usually the primary server) to determine if that server's zone file is a later version than the current copy of the zone file on the secondary server.
4. If a notified server determines that the serial number used in the SOA resource record of the notifying server's zone file is higher (more recent) than the serial number used in the SOA resource record for its current zone copy, a zone transfer is initiated. Otherwise, no update occurs and the notified server logs the attempted notify-update transaction as an error.

To determine which secondary servers in a zone to send the changes to, the source server for the primary zone contains a notify list, which is a list of the IP addresses for the secondary servers. The source server for the zone notifies only the listed servers when zone updates occur. To configure the notify list, open the zone Properties dialog box, click the Zone Transfers tab, and then click the Notify button. Select the Notify These Server Only option, type the IP address of each secondary server to notify when the zone is updated, and click the Add button. The notify list can also be used to restrict access to secondary servers that attempt to request zone updates.

DNS is most commonly associated with the Internet. However, many private networks also use DNS to resolve computer names and to locate computers within their local networks and the Internet. One benefit of DNS is that DNS names are user-friendly and are less likely to change than IP addresses. Another benefit is that it allows users to connect to local servers by using the same naming convention as the Internet.

The domain name space is the naming scheme that provides the hierarchical structure for the DNS database. The DNS database is indexed by name, so each domain (node) must have a name. The hierarchical structure of the domain name space consists of a root domain, top-level domains, second-level domains, any subdomains, and host names. Host names refer to specific computers on the Internet or a private network. A host name is the leftmost portion of a fully qualified domain name (FQDN), which describes the exact position of a host within the domain hierarchy.

Domain naming guidelines include limiting the number of domain levels, using unique names, and using simple names. Zones provide a way to partition the domain name space into smaller sections. A zone represents a discrete portion of the domain name space. A DNS name server stores the zone database file. There are two methods of replicating the zone database file. The first method is to do a full zone transfer (AXFR), which replicates the entire zone file. The second method is to do an incremental zone transfer (IXFR), which replicates only changes to the zone file. IXFR zone update is new to the Windows 2000 DNS Server Service, and it can reduce the amount of zone data that is transferred to fully update a zone.