This chapter is from the book
This chapter is from the book
This chapter is from the book
DNS
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 is not a requirement for Active Directory, but it is recommended. 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)
NOTE
Berkeley Internet Name Domain (BIND) DNS servers regard Active Directory– integrated zones as Standard Primary DNS zones. Active Directory–integrated zones can replicate DNS updates to other Active Directory–integrated zones or to Standard Secondary DNS zones. Because Active Directory–integrated zones can replicate DNS data to Standard Secondary DNS zones, you can use Active Directory–integrated zones with BIND servers hosting Standard Secondary DNS zones.
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).
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 Web site'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:
-
The client computer generates a request for the IP address of http://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.)
-
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 http://www.zandri.net from DNS server localcfg.zandri.net, localcfg.zandri.net would likely have the required information in its own database.
-
If LOCALCFG is unable to locate an entry for http://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.)
-
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 http://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.)
-
The LOCALCFG DNS server that received the client's recursive query sends an iterative query to the DNSNET server.
-
If the DNSNET server has an entry for http://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 http://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.)
-
The LOCALCFG DNS server sends an iterative query to the ZANDRIDNS server.
-
The ZANDRIDNS server locates an entry for http://www.zandri.net in its database and sends a reply to the LOCALCFG DNS server with the IP address of http://www.zandri.net.
-
The LOCALCFG DNS server sends a reply to the client computer with the IP address of http://www.zandri.net, which allows that client's Web browser to display the Web page on http://www.zandri.net.
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, as clients throughout the enterprise commonly query for the name resolution of those servers.
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.
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 http://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.)
NOTE
In some instances, it is practical and perhaps necessary to disable recursion on certain DNS servers. If your enterprise has a number of internal-only DNS servers, it is not necessary for those servers to continue attempting to resolve yahoo.com for your clients, for example.
By setting certain DNS servers to not perform recursive lookups, in effect external lookup resolutions would quickly fail (as they would not have local data for yahoo.com). This allows client systems to fail over to another DNS server they have been configured to use to resolve the external name. For this process to be effective, the other DNS server would have to be one that handles external lookups.
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.
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 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.
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. Also, 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 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.
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. 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).
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).
)
Figure
3.3 The option to create the DNS zone as Active Directory integrated is grayed
out because the server is not installed in the role of a domain controller.
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 with only the Standard Secondary servers functioning.
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.
NOTE
ACL permissions to update the DNS zone are made in the DNS zone container within Active Directory and can be assigned for the entire DNS zone or for individual resource records within the zone. They can also be assigned to systems, groups, or users.
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.
)
Figure
3.4 There are three options for changing the scope of DNS replication in Active
Directory.
NOTE
Active Directory–integrated DNS zone data replicated to application directory partitions is not replicated to the forest's Global Catalog. The domain controller containing the Global Catalog can also host application directory partitions, but it does not replicate this data to its Global Catalog.
Active Directory–integrated DNS zone data replicated to domain partitions is replicated to all domain controllers in its Active Directory domain, and a portion of this data is stored in the Global Catalog. This setting is used to support Windows 2000.
TIP
The default configuration of the Windows Server 2003 DNS service allows zone transfers only to servers listed in a zone's Name Server (NS) resource records. Administrators can increase the security of the zone transfer process by changing the setting to allow zone transfers to the specified IP addresses of those servers only.
If DNS zone transfers must take place over a public network, such as the Internet, you can protect replication data by using VPNs and IPSec encryption. Using Active Directory–integrated zones exclusively for replicating DNS zone data adds another layer of security to zone transfers.
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" http://www.zandri.net, as far as DNS resolution is concerned: There is an Alias record referencing http://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 a 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.
)
Figure
3.5 You can download DNS files from InterNIC to use with DNS.
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.4 shows the most common top-level domain names currently available on the Internet.
Table 3.4 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, as 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, as 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.
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.5 shows the properties that can be configured and the default settings.
Table 3.5 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 |