Planning, Implementing, and Maintaining a Network Infrastructure

This chapter is from the book 

Plan a Host Name Resolution Strategy

The Windows Server 2003 DNS Service offers a number of new features and enhancements, and many of the Windows 2000 features have been carried over as well. For example, you can configure conditional forwarders on your Windows Server 2003 DNS server to forward all DNS queries for a specific domain name to an IP address of a specific DNS server or servers. Conditional forwarders can be used in both intranet and Internet queries.

You can also use forward-only servers when you need to manage the DNS traffic between your network and the Internet. To do this, you configure the firewall your network uses so that only one DNS server is allowed to communicate with the Internet. This requires you to configure the other DNS servers in your enterprise to forward queries they cannot resolve locally to the Internet-enabled DNS server in the DMZ so that the query can be resolved.

The Windows Server 2003 DNS service provides basic support of the DNS Security Extensions (DNSSEC) protocol defined in RFC 2535, which allows DNS servers to perform as secondary DNS servers for existing DNSSEC-compliant, secure zones. Windows Server 2003 DNS supports storing and loading DNSSEC-specific resource records (RRs).

Microsoft DNS on Windows Server 2003 is compliant with most of the RFC specifications used to define the DNS protocol and allows deploying Active Directory under other DNS implementations. The Windows Server 2003 DNS service supports the following features:

• IETF Internet-Draft "A DNS RR for specifying the location of services (DNS SRV)" (SRV records)
• Dynamic updates
• Secure dynamic update based on the General Security Service Transaction Signature (GSS-TSIG) algorithm
• WINS and WINS R (reverse) records
• Fast zone transfer
• Incremental zone transfer
• Support for UTF (eight-character encoding)

DNS is the primary naming convention for Windows 2000 and 2003 domains; it provides name resolution for client systems by translating computer names to IP addresses so that computers can locate each other. DNS domains and Active Directory domains can share a common naming structure; in many cases, they are identical, but they can also be completely different. For example, Server1.gunderville.com is a valid Windows domain name and could be the internal name for a host. If that same server were available to the Internet for access, it could also use that naming convention if it was available. The best analogy for correlating DNS names with IP addresses is using the phone book to look up someone's name (the DNS name, in other words) to find his or her area code and phone number (that is, the IP address).

Understanding Name Resolution

There are two types of DNS lookup queries: forward and reverse. A forward lookup query resolves a DNS name to an IP address and is the most common DNS query. When you perform a forward lookup, such as entering http://www.zandri.net into a browser, your client looks up the website's IP address with the assistance of a DNS server behind the scenes. A reverse lookup query resolves an IP address to a name. A DNS name server can resolve a query only for a zone for which it has authority. When DNS servers receive a name resolution request, they attempt to locate the requested information in their own cache and local database.

DNS servers cache all external name resolution data for a specific interval called Time to Live (TTL). The default TTL for DNS resolution is one hour; for WINS lookups via DNS, the default is 15 minutes.

DNS administrators can adjust the default settings for the DNS cache by going to the zone's Properties dialog box and selecting the Start of Authority (SOA) tab. To change the 15-minute default setting for WINS, select the WINS tab and click the Advanced Settings button.

Configuring a shorter TTL interval ensures that DNS and WINS information is more up to date, but it also increases the load on your DNS server, your WINS server, and your network. You can increase the interval when network resources are a higher premium than "freshness" of name resolution.

Two types of queries can be performed in DNS: iterative and recursive. An iterative query happens when a client makes a DNS resolution query to a DNS server, and the server returns the best answer it can provide based on its local cache or stored zone data. If the server resolving the iterative query does not have an exact match for the name request, it provides a pointer to an authoritative server in another level of the domain namespace. The client system then queries that server, and continues this process until it locates a server that is authoritative for the requested name or until an error is returned, such as "name not found," or a timeout condition is met.

A recursive query happened when a client makes a DNS resolution query to a DNS server, and the server assumes the full workload and responsibility for providing a complete answer to the query. If the server cannot resolve the query from its own database, it performs separate iterative queries to other servers (on behalf of the client) to assist in resolving the recursive query. The server continues this process until it locates a server that is authoritative for the requested name or until an error is returned, such as "name not found," or a timeout condition is met.

In most cases, client computers send recursive queries to DNS servers, and usually the DNS server is set up to make iterative queries to supply an answer to the client. In the following query example, a client computer makes a request to a DNS server to resolve the web address http://www.zandri.net:

1. The client computer generates a request for the IP address of www.zandri. net by sending a recursive query to the DNS server it is configured to use in its network configuration. (Call this server LOCALCFG.)

2. The LOCALCFG DNS server looks in its local database for an answer. If it finds that answer locally, it is returned to the client. Usually this happens only if the server is authoritative for the DNS zone in question or if it is hosting secondary zone files for other DNS zones. If the client is client1.zandri.net and is looking for www.zandri.net from DNS server localcfg.zandri.net, localcfg.zandri.net would likely have the required information in its own database.

   For the purposes of the remainder of this description, assume that the client looking for http://www.zandri.net is not going to find DNS resolution on the local DNS server and that LOCALCFG is not a member of the zandri.net domain and does not host secondary zone files for the zandri.net domain.

   NOTE

   The answer to this DNS query might be in the local cache if the DNS server recently looked up this resolution request for another client. In a large enterprise with many DNS clients connecting to the Internet, it would not be uncommon for many of the largest Internet sites to be almost constantly present in the local DNS server's cache because clients throughout the enterprise commonly query for the name resolution of those servers.

3. If LOCALCFG is unable to locate an entry for www.zandri.net in its own database, it sends an iterative query to a DNS server that is authoritative for the root of the local domain. (Call this server LOCALROOT.)

4. If the LOCALROOT DNS server, which is authoritative for the root domain, has the answer in its local database, it sends a response to LOCALCFG. If the LOCALROOT DNS server is unable to locate an entry for www.zandri.net in its database, it sends a reply to the LOCALCFG DNS server with the IP address of a DNS server that is authoritative for the .net domain. (Call these servers DNSNETx; x would be the numerical designation of a particular server.)

5. NOTE

   If the address ends in .com, IP addresses of DNS servers that are authoritative for the .com domain are sent. For addresses ending in .org, IP addresses of DNS servers that are authoritative for the .org domain are sent, and so on.

6. The LOCALCFG DNS server that received the client's recursive query sends an iterative query to the DNSNET server.

7. If the DNSNET server has an entry for www.zandri.net in its local cache, it returns the answer to the LOCALCFG DNS server. If DNSNET is unable to locate an entry for www.zandri.net in its database, it sends a reply to the LOCALCFG DNS server with the IP addresses of DNS servers that are authoritative for the zandri.net domain. (Call this server ZANDRIDNS.)

8. The LOCALCFG DNS server sends an iterative query to the ZANDRIDNS server.

9. The ZANDRIDNS server locates an entry for www.zandri.net in its database and sends a reply to the LOCALCFG DNS server with the IP address of www.zandri.net.

10. The LOCALCFG DNS server sends a reply to the client computer with the IP address of www.zandri.net, which allows that client's web browser to display the web page on www.zandri.net.

When DNS clients make a request for a reverse DNS lookup, they are effectively making a request to resolve a hostname of a known IP address. In the standard DNS namespace, there is no connection between hostnames and IP addresses, and only a thorough search of all domains allows for reverse resolution.

Often, DNS servers are called on to resolve the same query multiple times within a short time. As an example, if a number of AOL users (arguably the largest ISP in the world) get an email reporting that new articles have been posted to www.2000trainers.com and immediately go to this site to read the new articles, the AOL DNS servers must continually recall the resolved address many times within a short period and use their local cache to do so.

DNS servers cache resolved addresses for a specific duration, specified as the TTL in the returned data. The DNS server administrator of the zone containing the data decides on the TTL setting. Therefore, the administrator of the 2000trainers.com domain and the DNS servers for that domain sets the TTL value. This value tells the resolving AOL DNS servers how long to hold that information in their cache. The lower the TTL, the "fresher" the resolution data is on the resolving AOL DNS servers.

After a DNS server caches data, it decreases the TTL from its original value so that it knows when to flush data from its cache. If another resolution query comes to the DNS server for the URL, the cached data is used and the TTL is reset (in most cases) to the original TTL. (The only time the TTL value isn't reset to its original value is if the administrator sets a different TTL.)

The in-addr.arpa domain was created to avoid query overloads on DNS servers. System names in the in-addr.arpa domain are listed by their respective IP addresses. Because IP addresses are designed so that they become more significant as you move from left to right in the address, and domain names get less significant from left to right, IP addresses in the in-addr.arpa domain are listed in reverse order.

Pointer (PTR) records are added to IP addresses and corresponding hostnames. To perform a successful reverse lookup of an IP address, such as 121.41.113.10, the DNS server performing the query looks for a PTR record for 10.113.41.121.inaddr.arpa, which has the hostname and IP address 121.41.113.10.

Planning DNS Servers

Before you can effectively implement DNS, you need to take some time to plan the infrastructure. This includes determining where your DNS servers are placed, how many DNS servers are required, what type of DNS server role best meets your requirements, and so on. The following section looks at some of the important topics that need to be considered when implementing DNS.

DNS Server Placement

There are two points that need to be considered where considering DNS Server placement. First, how many DNS servers do you require and second, where on the network will they be located.

DNS servers should be placed in a location where they are most accessible to DNS clients. Ideally, a DNS server should be placed on each subnet. When it comes to the number of DNS servers, you should have a minimum of two DNS servers for your zone. However, this will depend on the level of fault tolerance that you require.

DNS Server Roles

You can configure a DNS server in one of three possible roles: caching-only DNS server, primary DNS server, or secondary DNS server. The role the server plays depends on the configuration of zone files and how they are maintained. The zone files contain configuration information for the zone as well as the resource records.

Caching-only DNS servers perform name resolution on behalf of clients and then cache the resulting name resolutions. They are not configured to be authoritative for a DNS zone and do not store Standard Primary or Standard Secondary zones locally. Their local cache holds the most frequently requested names and associated IP addresses and are available for subsequent client queries. This helps reduce traffic across a WAN because a caching-only server attempts to locate information in its cache to resolve local client requests and queries across the WAN for name resolution only when the information needed to complete the name resolution request is not available.

Also, because a caching-only server does not maintain any zone files that need to be updated via replication, it does not generate any zone transfer traffic.

All DNS servers maintain a cache.dns file that contains a list of all Internet root servers. Any time a DNS server resolves a hostname to an IP address, the information is added to the cache file. The next time a DNS client needs to resolve that hostname, the information can be retrieved from the cache instead of the Internet.

A primary DNS server hosts the working (writable) copy of a zone file. If you need to make changes to the zone file, it must be done from the server that is designated as the primary server for that zone. For those of you who are familiar with Windows NT 4.0, this is similar to how the primary domain controller (PDC) maintains the working copy of the directory database. After a server is configured as a primary DNS server for a zone, it is said to be authoritative for that domain. In addition, a single DNS server can be the primary DNS server for multiple zones.

A secondary server gets all its zone information from a master DNS server. The secondary DNS server hosts a read-only copy of the zone file, which it gets from the primary server or another secondary DNS server. Through a process known as a zone transfer, the master DNS server sends a copy of the zone file to the secondary server. The server responsible for the transfer of information to a secondary DNS server is known as a Master server.

For example, if Server2 is configured as a secondary server for bayside.net, Server2 would get all of its zone information from Server1, the primary DNS server for the zone. Any changes that need to be made to the zone file would have to be done on Server1. The changes would then be copied to Server2. As already mentioned, a DNS server can be both a primary and a secondary server at the same time. Using this example, Server2 could also be configured as the primary server for riverside.net, and, to provide fault tolerance for the zone file, Server1 could be configured as a secondary server for this zone.

Secondary DNS servers provide the following benefits:

• Fault tolerance—Because the secondary server has a copy of the zone file, name resolution can continue if the primary DNS server becomes unavailable.
• Reduction in name-resolution traffic—Secondary servers can be placed in remote locations with a large number of users. Clients can then resolve hostnames locally instead of having to contact a primary DNS using a WAN link.
• Load balancing—Name-resolution services for a zone can be provided by the secondary server as well, thereby reducing the load placed on the primary DNS server.

DNS Zone Overview

A DNS zone is a contiguous portion of the domain namespace for which a DNS server has authority to resolve DNS queries. DNS namespaces are almost always divided into zones, which store name information about one or more DNS domains or portions of a DNS domain.

In the Windows Server 2003 Active Directory domain structure, there are three different zone types: Standard Primary zones, Standard Secondary zones, and stub zones.

Standard Primary Zones

Standard Primary zone files contain a read/write version of the zone file that is stored in a standard text file. Any changes to the zone are recorded only in that file. Any other copies of that zone are Standard Secondary zone copies and are read-only.

Standard Secondary Zones

A Standard Secondary zone file contains a read-only version of a Standard Primary zone file stored in a standard text file. Any changes to the zone are performed on the Primary zone file and replicated to the Secondary zone file. You create a Standard Secondary zone to make a copy of an existing Standard Primary zone and its zone file, which allows the DNS name resolution workload to be distributed among multiple DNS servers, thus providing a certain level of fault tolerance and load balancing. In addition, for remote sites, a Standard Secondary zone on that local site keeps local user systems from consuming unnecessary bandwidth by going over the WAN to query the DNS server. In most cases, local user systems are configured with the local DNS server that hosts the Standard Secondary zone as their primary DNS server, and perhaps another DNS server (at the main site) as a secondary DNS server.

Stub Zones

Stub zones allow a DNS server that is authoritative for the parent zone to be kept aware of other authoritative DNS servers for its child DNS zones in an effort to maintain DNS name resolution parity. Configuring stub zones enables administrators to distribute a list of the authoritative DNS servers for a zone without using Standard Secondary zones. Stub zones do not serve the same purpose as Standard Secondary zones and should not be used explicitly for redundancy and load balancing.

Active Directory Integrated Zones

Active Directory Integrated zones store DNS zone information in the Active Directory database rather than a text file. The Active Directory Integrated option is not available in the Change Zone Type dialog box unless the DNS server is also a domain controller. If the DNS server is not configured as a domain controller in your environment, the option to create the zone as Active Directory Integrated is grayed out during the creation of the zone (see Figure 3.3).

Zone Data Replication

When replication is considered for Standard zone types, Primary zones are the only read/write copy of the DNS zone database, and only one Standard Primary zone exists. You can replicate the zone to any number of Standard Secondary DNS zones as needed, and these zones are read-only copies of the zone information. The only place where updates to the DNS zone database can occur is on the Standard Primary copy of the zone. The changes recorded there are replicated incrementally by incremental zone transfer (IXFR) or by transferring the entire zone database via full zone transfer (AXFR).

Although a Standard Primary DNS server with multiple Standard Secondary servers is fault tolerant and load-balanced to a degree, the loss of the Standard Primary DNS server prevents updates to the DNS database until an administrator can intervene. The administrator needs to repair the downed Standard Primary DNS server or promote a Standard Secondary DNS server to a Standard Primary DNS server. Name resolution still occurs for the first 24 hours with only the Standard Secondary servers functioning then all the records on the secondary servers will expire.

DNS zone transfers occur on a preconfigured basis, which is set to 15 minutes by default. This preconfigured basis is called a refresh interval, and its setting is found in the Start of Authority (SOA) tab of a zone's Properties dialog box. When the refresh interval expires, DNS servers request a copy of the current SOA record for their zone.

The DNS server then compares the serial number of the source DNS server's current SOA record with the serial number in its own local SOA record. If the responding DNS serial number is higher, the DNS server requests a zone transfer from the Primary DNS server. If a network issue or some other error prevents the zone transfer, the requesting DNS server retries the request for a zone transfer at a preconfigured interval, which is called a retry interval and is set to 10 minutes by default.

If the failure is persistent and a zone transfer cannot be completed, the requesting DNS server quits making requests for a zone transfer after the expire interval (default setting is one day) has been exceeded. Active Directory–integrated DNS zones store zone information in Active Directory and are multimaster in nature, which enables administrators to configure systems so that updates to the DNS database can occur on any domain controller hosting the DNS zone. This type of setup is fully load balanced and fault tolerant; the loss of any single DNS server does not affect DNS name resolution or updates to the DNS database because any DNS server can receive updates.

Because Active Directory–integrated zones store zone information in Active Directory, the DNS information is replicated along with other Active Directory data. This configuration also enables administrators to establish permissions using Access Control Lists (ACLs) to allow only authenticated systems, groups, or users to make updates to the DNS zone.

Active Directory–integrated zones can be configured for the following types of replication (see Figure 3.4):

• Replication can be configured so that all DNS servers in the Active Directory forest can replicate DNS zone data to all DNS servers running on domain controllers within the Active Directory forest. (For the most part, this is the Active Directory–integrated DNS zone replication in Windows 2000 Server.)
• Replication can be configured so that all DNS servers in the Active Directory domain can replicate DNS zone data to all DNS servers running on domain controllers in the local domain. This is the default Active Directory–integrated DNS zone replication setup in Windows Server 2003.
• Replication can be configured so that all domain controllers in the Active Directory domain can replicate DNS zone data to all domain controllers in the Active Directory domain. You can use this setting if you need Windows 2000 DNS servers to load a specific Active Directory zone.
• Replication can be configured so that all domain controllers in a specified application directory partition can replicate DNS 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.

DNS zone files contain the name resolution data for a zone and include resource records with database entries containing various attributes of network systems. The most common resource records are discussed in the following sections.

(A) Records

Sometimes called host records or address records, (A) records contain the name–to–IP address mapping information used to map DNS domain names to a host IP address on the network. The following are examples of host or (A) records:

server1        IN A 121.41.113.10
localhost      IN A 127.0.0.1

Alias Records

Normally referred to as CNAME (canonical name) records, Alias records allow you to provide additional names to a server that already has a name in an (A) resource record. This is how a web server with a name of Server1 in a domain of zandri.net "becomes" www.zandri.net, as far as DNS resolution is concerned: There is an Alias record referencing www.zandri.net to Server1.zandri.net. Here are some examples of using CNAME records:

www           CNAME Server1
ftp           CNAME Server1

MX (Mail Exchanger) Records

MX (Mail Exchanger) records specify which server email should be delivered to in a domain. When you have a mail server named Mailbox.zandri.net and you want all mail for all_users@zandri.net to be delivered to this mail server (named Mailbox in this example), the MX resource record must exist in the zone for Zandri.net and point to Mailbox.

NS (Name Server) Records

NS (Name Server) records designate DNS domain names for the servers that are authoritative for a DNS zone and can list additional name servers within the record. The following is an example of an NS record:

@ IN NS server2.zandri.net

The at symbol (@) in a database file indicates "this server" and the IN indicates an Internet record.

PTR (Pointer) Records

PTR (Pointer) records are used for reverse lookup queries that resolve IP addresses to names. Reverse lookup zones are created in the in-addr.arpa domain to designate a reverse mapping of a host IP address to a host DNS domain name.

As mentioned previously, to perform a successful reverse lookup of an IP address, such as 121.41.113.10, the DNS server performing the query looks for a PTR record for 10.113.41.121.in-addr.arpa, which has the hostname and IP address 121.41.113.10. The PTR record for it looks like this:

10.113.41.121.in-addr.arpa. IN PTR Server1.Zandri.net.

Reverse lookup zones are not a requirement; they are an optional configuration for your DNS server in most cases. In certain situations, a reverse lookup zone might be required to verify the location of connecting clients.

SOA (Start of Authority) Records

SOA (Start of Authority) records indicate the starting point of authority for a DNS zone on a specific DNS server. The SOA record is the first resource record created when you add a new zone. The following is an example of an SOA record:

@ IN SOA server1.zandri.net. (
                               1        ; serial number
                               7200   ; refresh [2h]
                               900     ; retry [15m]
                               86400 ; expire [1d]
                               7200 ) ; min TTL [2h]

The at symbol (@) in a database file indicates "this server." IN indicates an Internet record. Any hostname not terminated with a period has the root domain appended. The @ symbol is replaced by a period in the administrator's email address. Parentheses must enclose line breaks that span more than one line. The 7200 ; refresh [2h] shows a refresh interval of two hours, 900 ; retry [15m] shows a retry interval of 15 minutes, 86400 ; expire [1d] shows an expire interval of one day, and 7200 ; min TTL [2h] shows a minimum TTL of two hours. Everything after a semicolon (;) is a comment, which is why line breaks are necessary.

SRV (Service) Records

Sometimes referred to as Service Location records, SRV (Service) records contain registered services within the zone so that clients can locate these services by using DNS. SRV records are mainly used to identify services in Active Directory.

The CACHE.DNS file contains the records of the root DNS servers. The cache file is basically the same on all name servers and must be present for a DNS server to handle a query outside its zone. The file provided by default with the Windows 2003 DNS server has current records for all the root servers on the Internet. This file is stored in the %SystemRoot%\System32\Dns folder when you install DNS on your Windows Server 2003 server.

If you are running DNS for internal use, not for connections for forwarding to the Internet, the CACHE.DNS file should be replaced to contain the name server's authoritative domains for the root of the private network. In certain situations, you replace the CACHE.DNS file in the %SystemRoot%\System32\Dns folder, and it does not update the root hints listed in the DNS Manager. This can happen because the DNS server is a domain controller configured to load zone data on startup from Active Directory and the Registry. If the root hints specified in Active Directory have been deleted, modified, incorrectly entered, or damaged, this behavior occurs. There is more information on CACHE.DNS in "Need To Know More?" at the end of this chapter.

Root hints consist of a list of resource records that the DNS service can use to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree in your enterprise. For DNS servers that have been deployed to resolve names external to your environment, root hints host addresses for the Internet root servers. When a new server is added or removed from your DNS structure, administrators might need to update the root hints list.

For a current copy of the root hints file for Internet root servers, you can download a copy of the named.root file from ftp://ftp.internic.net/domain/. Figure 3.5 shows the DNS files you can download from InterNIC for DNS use.

Choosing a DNS Namespace

You must take a number of considerations into account when you are planning your DNS namespace design. When setting up DNS in your environment, you should register a unique parent (second-level) DNS domain name that can be used for hosting your organization on the Internet, such as "zandri" in zandri.net or "2000trainers" in 2000trainers.com. Even if you are not currently connected to the Internet via your proposed domain name or are not considering it in the near future, you should still make an effort to register your DNS domain name because you can't accurately predict what course your company might take in the future. If your company does decide to establish an Internet presence, you might find that the name you are currently using is registered to someone else. In that case, not only will you be unable to use it, but you will have to redesign your entire DNS deployment.

Also, you need to consider to which top-level domain name you will tie your second-level name. Table 3.3 shows the original top-level domain names currently available on the Internet. Keep in mind that 2 letter country codes and many new top level domain names are not available.

Table 3.3. Top-Level Domain Names

Top-Level Name	Description	Traditionally Used By
arpa	Run by Advanced Research Project Agency (ARPA). Used to register reverse mapping of IPv4 addresses assigned to DNS domain names for computers that use those addresses on the Internet.	The in-addr.arpa domain
com	For business and commercial use.	Businesses and corporations
edu	For educational use.	Public and private schools, colleges, and universities
gov	For use by government institutions.	Local, state, and federal government agencies
int	Reserved for international use. Currently planned for use in RFC 1886 to register reverse mapping of IPv6 addresses assigned by IANA to DNS domain names in the ip6.int domain for computers that use those addresses on the Internet.	The ip6.int domain
mil	For use by military agencies.	Department of Defense (DoD), U.S. Navy, U.S. Army, U.S. Air Force, and other military agencies
net	For use by organizations that provide large-scale Internet or telephony-based service.	Large-scale Internet and telephone service providers
org	For use by noncommercial, nonprofit organizations.	Noncommercial, nonprofit organizations and charitable institutions

After your parent domain name is in place, you can configure other child names as needed. For example, forums.2000trainers.com can be created as a child of 2000trainers.com for resources the forums section of 2000trainers uses, and additional child domains could be established as needed. The domain might be broken down by geographical region, in which us.forums.2000trainers.com is one child domain and canada.forums.2000trainers.com is another.

Active Directory domains often correspond directly with DNS names. When choosing DNS names to use for Active Directory, starting with the registered DNS domain name suffix your organization has reserved for use on the Internet is best. Effectively, it means that internal and external namespaces are the same. For example, Zandri.net is what you can reach from the Internet and the intranet. The main benefit is that users access one domain name when they need to find resources, regardless of where those resources exist.

This common naming scheme causes a certain amount of additional administration to make certain that appropriate DNS and SRV records are stored on internal and external DNS servers. You could also use a delegated namespace internally, so that 2000trainers.com is reachable from the Internet and the Active Directory namespace is set up with something along the lines of corp.2000trainers.com.

This configuration offers better security because users and computers outside the organization cannot access the private DNS namespace from standard Internet connections with the proper segmentation of DNS zones. There is also less administrative overhead for DNS and SRV records because the zones for both namespaces are independent of each other. This setup could cause some confusion for internal users, however, if they need to access certain network resources from the external domain.

Optionally, the entire internal Active Directory namespace can be totally separate from the external namespace, so that zandri.net is used from the Internet and mcmcse.com is used internally. This configuration also offers better security because users and computers outside the organization cannot access the private DNS namespace from standard Internet connections with the proper segmentation of DNS zones. There is also less administrative overhead for DNS and SRV records because the zones for both namespaces are independent of each other. This setup could also cause confusion for internal users, however, if they need to access certain network resources from the external domain.

Zone Delegation

Delegation is the process of designating a portion of the DNS namespace for another zone. It gives administrators a way of dividing a namespace among multiple zones. For example, an administrator might place the bayside.net domain in one zone and place the sales.bayside.net subdomain in another delegated zone. The bayside.net zone would contain all the records for the sales subdomain if it is not delegated. Through delegating, the bayside.net zone contains only information for bayside.net, as well as records to the authoritative name servers for the sales.bayside.net zone. The host entries for any machines in sales.bayside.net are contained only on the delegated server.

In any case, when deciding whether to delegate, keep the following points in mind:

• Zone delegation allows you to delegate management of part of the DNS namespace to other departments or locations.
• Zone delegation allows you to distribute a large DNS database across multiple servers for load balancing, faster name resolution, and increased performance.
• Zone delegation allows you to extend the namespace for business expansion, that is, it is scalable with business needs.

Optimizing DNS

Administrators can optimize DNS servers in the enterprise by disabling local subnet prioritization and round-robin rotation. Local subnet prioritization is used so that clients on the same subnet as the available DNS server, based on IP address location, have priority over other DNS clients. Round-robin rotation of available DNS servers provides network load balancing. Disabling either or both settings reduces and balances client response time, for the most part, across the entire enterprise. Both settings are enabled by default.

Other DNS configurations can be modified from their default settings in an effort to tailor preferences to a locale's specific needs. To adjust these settings, right-click the DNS server in the DNS MMC, choose Properties, and select the Advanced tab of the Properties dialog box. Table 3.4 shows the properties that can be configured and the default settings.

Table 3.4. Default DNS Settings in Windows 2003 Server

Property	Default Settings
Disable recursion	Off
BIND secondaries	On
Fail on load if bad zone data	Off
Enable round robin	On
Enable netmask ordering	On
Secure cache against pollution	On
Name checking	Multibyte (UTF8)
Load zone data on startup	From Active Directory and Registry
Enable automatic scavenging of stale records	Off

Client Dynamic Updates and DHCP

You can configure DHCP servers in your enterprise to dynamically update DNS when the DHCP server assigns a DHCP client computer IP information, or you can allow clients to dynamically update DNS.

DNS clients running Windows 2000, Windows XP, and Windows Server 2003 operating systems can dynamically update DNS on startup. When DNS clients are allowed to update DNS, they connect to the DNS server on startup and automatically register the appropriate client information, such as the system IP address and the fully qualified domain name (FQDN), with the DNS server, regardless of whether their IP addresses are entered manually or assigned via DHCP.

To have clients dynamically update DNS, in the Network dialog box, select the client's active network connection, and choose Properties. Select Internet Protocol (TCP/IP), and click the Properties button. In the General tab, click the Advanced button to open the Advanced TCP/IP Settings dialog box, and then select the DNS tab (see Figure 3.6).

DNS dynamic update is enabled by default. You can configure additional dynamic update settings with the DHCP console. To do this, right-click the DHCP server in the left pane and choose Properties. In the DNS tab (see Figure 3.7), select the Enable DNS dynamic updates according to the settings below check box. Then choose whether to allow the DHCP server to make the updates or to override client settings and always perform updates.

You can also set the DHCP server to update A and PTR records of clients that do not make any dynamic update requests, such as Windows NT 4 systems. On the DNS server, you specify the DHCP server as the only computer authorized to update DNS entries.

If you use multiple Windows Server 2003 DHCP servers on your network and configure your zones to allow secure dynamic updates only, you need to add your DHCP servers to the built-in DnsUpdateProxyGroup to grant all your DHCP servers secure rights to perform updates for your DHCP clients. The default Discretionary Access Control List (DACL) entries on the DNS zones stored in Active Directory are as follows:

• Administrators have Allow settings for the following: Read, Write, Create All Child Objects, Special Permissions
• DnsAdmins have Allow settings for the following: Full Control, Read, Write, Create All Child Objects, Delete Child Objects
• Domain Admins have Allow settings for the following: Full Control, Read, Write, Create All Child Objects, Delete Child Objects
• Enterprise Admins have Allow settings for the following: Full Control, Read, Write, Create All Child Objects, Delete Child Objects
• Enterprise Domain Controllers have Allow settings for the following: Special Permissions
• Pre-Windows 2000 Compatible Access has Allow settings for the following: Special Permissions
• System has Allow settings for the following: Full Control, Read, Write, Create All Child Objects, Delete Child Objects