Planning for Host Name Resolution


EXAM 70-293 OBJECTIVE 2.7

One of the most common sources of trouble on any Windows network—whether it’s a Windows NT, Windows 2000, or Windows Server 2003 network—is faulty name resolution. Computers cannot resolve the computer names to the proper IP addresses, or they cannot find an IP address associated with a computer name at all. When name resolution (the process of finding the IP addresses associated with computer names and services running on those computers) is not working perfectly, a multitude of problems can arise, including (but not limited to) the following:

  • Users might not be able to log on to the network.

  • Users might not be able to connect to applications and services residing on remoter computers.

  • Domain controllers might not be able to communicate with each other.

In fact, problems with name resolution are so common that a typical first step in troubleshooting problems on a Windows network is to ensure that name resolution is working flawlessly. A common mantra that reflects this situation is the following: “The problem is irrelevant. The answer is DNS.” Although this is a gross oversimplification of the problems that can arise on a Windows network, it does contain a germ of truth.

It is critically important that an appropriate name resolution strategy be planned, implemented, and maintained on every Windows network. Starting with Windows 2000, correct host name resolution is a necessary condition for the proper operation of the network. This contrasts with Windows NT 4 and earlier networks in which correct NetBIOS name resolution is a necessary condition for the proper operation of the network. NetBIOS name resolution can still play an important and central role in Windows 2000 and 2003 networks; However, its importance is subordinate to that of host name resolution, and in some situations reliance on NetBIOS name resolution can be completely eliminated with careful planning.

Planning for host name resolution on a Windows Server 2003 network means developing and implementing a fault-tolerant and secure strategy, whereby host computers on the network are always able to resolve computer names to IP addresses and locate services running on the network in a timely manner. For example, to log on to a Windows Server 2003 network, client computers must be able to locate domain controllers that are able to process logon requests. On a Windows Server 2003 network, the primary mechanism for locating the domain controllers is host name resolution through DNS.

Understanding Host Naming

We have mentioned two different kinds of name resolution: host name resolution and NetBIOS name resolution. In order to understand host naming, you might find it useful to understand the differences between NetBIOS and host names. In the following sections, we’ll discuss the characteristics of each.

NetBIOS over TCP/IP

NetBIOS was originally developed to run on small broadcast-based networks. An early and commonly implemented network/transport protocol that relies on NetBIOS is NetBEUI, which is designed to run on a segment. NetBIOS itself was not designed to run on multisegment networks, and it was not initially designed to run on TCP/IP networks. For NetBIOS applications to work properly, they must be able to locate computers by their NetBIOS computer names. An example of the use of a NetBIOS application is the use of the Universal Naming Convention (UNC) path to gain access to a share on a remote computer. The UNC path has the form \\computername\sharename.

On a single-segment network running NetBEUI, a computer trying to connect to a file share on a remote computer sends a broadcast request to find the Media Access Control (MAC) address (a unique 12-digit hexadecimal number on Ethernet networks) associated with the network adapter of the target computer. After it receives a reply to its request for the MAC address of the computer that owns the NetBIOS name, the requesting computer can establish a session with the target computer. NetBIOS names either belong exclusively to the device, such as a NetBIOS computer name, or they are group names that are not exclusive, such as domain names. In either case, each NetBIOS name must be unique on the network.

On a TCP/IP network, IP addresses, rather than NetBIOS names, are used to connect to destination hosts. The process of IP address resolution is similar to NetBIOS resolution in that it is broadcast-based. When a computer tries to establish a connection with a destination host on the same network segment, it sends out a broadcast request for the MAC address of the computer configured with the IP address of the destination host. When the destination host is on a separate network segment, it sends a request for the MAC address of the default gateway. When the computer learns the MAC address of the destination host (or the default gateway, if the host is on a remote subnet), it can begin communicating with it.

Obviously, for NetBIOS applications running on TCP/IP networks, some method must be implemented so that these applications can use computer names and resolve them to the appropriate IP and MAC addresses. This is accomplished through the use of a specific NetBIOS interface called NetBIOS over TCP/IP, also known as NetBT or NBT, implemented in the Windows TCP/IP protocol stack. This interface allows NetBIOS applications to translate NetBIOS names to IP addresses, which are then subsequently used to resolve to the appropriate MAC address (the MAC address of the destination host, if on the same local subnet, or the default gateway, if on a remote subnet).

Host Names

NetBIOS names are required only when using NetBIOS applications that provide access to services running on remote or local computers. In contrast, WinSock applications, which are specifically written to run on a TCP/IP stack, use the WinSock interface in the Windows protocol stack. These applications include Web browsers and servers, FTP servers and clients, Internet e-mail clients and servers, and so on. However, since these applications are specifically designed to run on TCP/IP networks, they rely on IP addresses and not names to establish communications with a remote computer. Unlike the case with NetBIOS applications, it is not necessary to use a name to establish communications. When using a WinSock application, you need to use only the IP address of the destination host to establish communications. Host names are used in place of IP addresses to make it easier for the human operators of computers. It is much easier for most of us to remember a name than it is to remember a number.

In contrast to NetBIOS names, there is no necessary relationship between host names and the IP addresses of the computers they represent. In fact, multiple host names can be assigned to the same IP address, and a single host name can be assigned to multiple IP addresses. This last technique is used, for example, to provide a type of simple load balancing (round-robin DNS resolution) among multiple Web servers that are all hosting the same Web site. Also, unlike NetBIOS names, host names are not a necessary part of the configuration of the computer. A Web server, for example, does not need to be configured with the host name used to reach it.

For host names to resolve to the appropriate target computer IP address, the client computer needs to have some means of being able to resolve the host name to the remote IP address. There are two primary methods for resolving host names to IP addresses: using a hosts file or using a DNS server. (On a Windows network, the situation is a little more complicated, because methods of NetBIOS name resolution can be used when host name resolution fails.)

Understanding the Hosts File

The hosts file is a text file that is found on the local computer. On Windows-based computers, the path to the hosts file is %systemroot%\system32\drivers\etc\hosts, where %systemroot% is a variable used to identify the folder where the operating system is installed, such as C:\Winnt or C:\Windows.

Note

Even though the hosts file is a text file, it does not have a .txt extension. Therefore, you must ensure that the file is not saved with this extension appended to it. For example, if you open the file in Notepad and then save it as a text file the .txt extension will be the default. Then Windows will not recognize the hosts file. This can be particularly problematic on Windows machines that are set to hide common file extensions by default, because the file will appear to not have the extension when you view it in the file list in Windows Explorer. This is one of the first things you should check if you have a hosts file that doesn’t seem to be working.

The hosts file contains a list of host names and the IP addresses associated with them. By default, the hosts file contains only one active entry for the host name localhost, which points to the loopback IP address of 127.0.0.1.

The structure of the file is simple. To add a host name to IP address mapping, simply insert a new line containing the IP address of the destination computer followed by the host name. You can enter either a simple name or a fully qualified domain name (FQDN) that contains dots, such as www.syngress.com.

Although the hosts file has largely been superceded by DNS as a method of name resolution, it still has a number of valid uses. For example, you can use it to substitute a shorter, simpler name for a longer, more complex name that is stored on a remote DNS server. You can also use it for testing purposes. Another purpose of the hosts file is to use it to deliberately block Web sites, such as those that serve banner ads on Web sites, by mapping the FQDN of the Web sites to the loopback address (127.0.0.1) of your computer. This technique is useful if you want to speed up browsing on Web sites and do not wish to be subjected to large numbers of banners ads. (See http://pgl.yoyo.org/adservers/ for more information about this use.)

The use of a hosts file can also speed up the process of host name resolution. When you try to connect to a remote computer using a host name, Windows operating systems prior to Windows 2000 will first consult their DNS cache stored in memory, then consult the hosts file, and then consult the DNS server. Beginning with Windows 2000, the hosts file is parsed whenever modifications are made to it and the contents are stored in the DNS resolver cache, eliminating the second step. Prior to Windows 2000, the hosts file is parsed every time host name resolution is required and the result is not found in the DNS cache.

To verify that the contents of the hosts file are stored in the DNS cache, open a command prompt and enter the command ipconfig /displaydns. This will display the contents of the DNS cache. Make a modification to the hosts file and save it. Then run the same command again. You will see the entry you made in the hosts file listed in the DNS cache. Figure 6.1 shows the output of the ipconfig /displaydns command after the hosts file had been saved with the addition of a host record named test_record, pointing to 192.168.100.1.

click to expand
Figure 6.1: Output of the ipconfig /displaydns Command Showing the Contents of the DNS Cache

Understanding DNS

In the early days of the Internet (prior to 1984), there was no such thing as DNS. A single individual was responsible for updating a hosts.txt file whenever computers were added to the network. This hosts file was downloaded to other computers in order to maintain an up-to-date list of host names. Obviously, this solution was not effective when large numbers of computers were added to the Internet. The solution that replaced the use of the hosts file was DNS.

A DNS server is a computer that contains a database of host names and IP addresses. A computer configured as a DNS client can use the DNS server to query the database for the purpose of resolving names to IP addresses. An important characteristic of DNS is that the DNS server itself runs on a remote computer and will resolve names to IP addresses, as long as the DNS client has access to it.

There are many DNS servers in use on the Internet. Collectively, these DNS servers comprise a distributed, hierarchical database containing resource records (RRs) that allow DNS clients to resolve the host names to IP addresses in the case of forward lookup zones, and IP addresses to host names in the case of reverse lookup zones. DNS is also responsible for supplying mail routing and other information for various Internet applications. Because the billions of RRs that compose the DNS database are distributed, and because DNS uses an efficient protocol for name resolution (UDP), its performance is exceptional and is for the most part unaffected by the very large number of host names to IP addresses that it must resolve on a daily basis.

start sidebar
Configuring & Implementing...
Understanding Common Resource Records (RRs)

Knowing the nature and purpose of common DNS resource records (RRs) is important to an understanding of DNS in general. RRs are defined in RFC 1034. However, since the publication of this RFC, a number of new RR types have been added. RRs have the following components:

  • Owner Name The domain name where the RR is found.

  • Type A 16-bit value that identifies the type of RR such as an A, a PTR, an NS, an MX, or an SOA record.

  • Time To Live (TTL) The amount of time that an RR will be cached on a server. This is an optional field for many RRs.

  • Class A 16-bit value that identifies the class of the resource, such as IN for Internet. Windows Server 2003 DNS supports only the IN class. This is a mandatory field.

  • RDATA A required field that contains information describing the resource. The length and format of this information vary according to the type and class of the RR.

    Common RR types include the following:

  • A Address record used to map names to IP addresses. When a DNS client queries for an address record, it will receive an IP address in the reply. Here is an example:

    host1.syngress.com.  IN  A 192.168.100.5
  • PTR Pointer record used to map IP addresses to names in reverse lookup zones. When a DNS client queries for a PTR record, it will receive a FQDN as the reply. Here is an example:

    5.100168.192.in-addr.arpa.    PTR  host1.syngress.com.
  • MX Message Exchanger record used to identify name(s) and priority of server(s) responsible for handling Simple Mail Transfer Protocol (SMTP) mail for a domain. Note in the following example that a specific host is identified for handling mail for the domain. A corresponding address record must be associated with the host name.

    syngress.com.    MX  10 host1.syngress.com.
  • NS Name Server record used to identify name servers that are responsible for identifying DNS servers for DNS resolution for a domain. Note in the following example that a specific host is identified for authoritative name servers for the domain. A corresponding glue address record must be associated with the host name.

    syngress.com.    IN NS  ns1.syngress.com
  • CNAME Canonical name used to map an alternate or aliased name to a primary or canonical domain name. The canonical name must exist, and there can be only one CNAME per alias. Here is an example:

    aliasname.syngress.com  CNAME www.syngress.com
  • SRV Service locator record that all allows multiple servers hosting TCP/IP-based services to be located by means of a DNS query. This is used extensively to support AD. For example, SRV RRs allow clients to locate domain controllers that can process logon requests. Here is an example:

    _ldap._tcp._msdcs    SRV  0 0   389 dc1.syngress.com                      SRV 10 0   389 dc2.syngress.com
  • SOA Start of Authority record used to indicate the name of origin for the zone, the name of the server that is the primary authority for the zone, and other properties (such as e-mail of the responsible administrator, the version number of the zone data file, and other fields). This record is always the first record to appear in the DNS data. In the following example, note the @ on the left side to designate the owner for the RR. This symbol is a shorthand designator to indicate the origin (domain name). It can be used with any record, but it is most often used with the SOA record.

    @   IN  SOA     ns1.syngress.com.  dnsadmin.syngress.com. (                    1            ; serial number                    3600      ; refresh   [1h]                    600        ; retry     [10m]                    86400    ; expire    [1d]                    3600 )    ; min TTL   [1h]

    The fields in the SOA record merit some special attention:

  • The serial number indicates the version number of the zone file. When this number is incremented on a primary DNS server, a secondary DNS server that is polling the primary DNS server will learn that it needs to update its zone file through a zone transfer.

  • The refresh interval indicates the length of time a secondary DNS server will wait before polling the primary DNS server to determine if it needs to copy the DNS data from the primary DNS server. This setting can be used to control the frequency of zone transfer traffic to secondary DNS servers.

  • The retry interval indicates how long a secondary DNS server will wait after a failed zone transfer before trying again.

  • The expire interval indicates how long a secondary DNS server will keep its records after failing to contact the primary DNS server. This prevents a secondary DNS server from retaining out-of-date data.

  • The min TTL is the length of time a DNS resolver will cache records that it has queried on this server. The min TTL is a global value that is applied to all records, unless a specific TTL is specified in a particular RR.

Windows Server 2003 DNS also supports new RR types for IPv6, such as the AAAA RR for 128-bit IPv6 address. Here is an example of an AAAA RR:

host1.syngress.com.     IN  AAAA       4321:123:12:322:3:4:567:34de

For more information about DNS extensions to support IPv6, see RFC 1886 at www.rfceditor.org/rfc/rfc1886.txt. For more information about IPv6, see Chapter 3 of this book.

end sidebar

The hierarchical tree on which DNS is based is called the domain namespace. At the top of the domain namespace is the root, or the dot (.), domain. Below the root domain are the various subdomains, beginning with the top-level domains, such as .com, .net, edu, and the various domain names that indicate country codes, such as .ca, .us, .de, and so on. Below the top-level domains are subdomains, referred to as the second-level domains, such as microsoft.com, syngress.com, and so on. These second-level domains can have further subdomains, such as authors.syngress.com or research.microsoft.com. Figure 6.2 shows an example of the hierarchical domain namespace.

click to expand
Figure 6.2: Hierarchical DNS Namespace

In the example in Figure 6.2, the domain research.microsoft.com contains an RR for a host called www. When the name of the host is concatenated with the complete domain name from right to left (www.research.microsoft.com), the result is the FQDN for the host. The FQDN indicates the full path from the host to the root domain when read from left to right.

A true FQDN includes a period at the rightmost end of the domain name to indicate termination at the root zone. Thus, www.research.microsoft.com. (with the period at the end) is the true FQDN. This point is a source of some confusion among administrators, because they normally do not include this rightmost period when they, for example, type a destination in a Web browser. However, the output of diagnostic utilities such as NSLookup will be affected if you do not include the period.

Domains versus Zones

It is critically important to understand the difference between domains and zones. As you can see in Figure 6.2, the domain namespace is partitioned into various subdomains. However, the hierarchy is also partitioned into various zones. A zone comprises the total set of RRs contained in an authoritative name server for a domain and its subdomains, starting from a particular point in the DNS hierarchy.

Consider, for example, the domain microsoft.com. This domain and its subdomain, research.microsoft.com, might consist of a single zone administered by authoritative name servers in the microsoft.com domain; that is, all the RRs for the parent and its subdomain are contained in the same authoritative name servers. However, it is possible to delegate authority for the subdomain, research.microsoft.com, to another set of name servers through the use of NS and A RRs. When this delegation of administrative authority takes place, the subdomain is administered by a separate zone. The authoritative name servers for the parent domain, microsoft.com, do not contain records for the subdomain, with the exception of those records that are necessary to delegate authority for the subdomain to other name servers. Figure 6.3 illustrates two possible zone configurations for the microsoft.com domain.

click to expand
Figure 6.3: Zones versus Domains

The left side of Figure 6.3 represents a zone of authority, which includes both the parent and the subdomains for microsoft.com. The authoritative name servers in the parent domain contain all the RRs for the parent and the subdomain. In the example in Figure 6.3, a name server called ns1.microsoft.com holds all of the RRs for the three domains: microsoft.com, dev.microsoft.com, and research.microsoft.com.

The right side of Figure 6.3 shows a delegation of authority from the parent domain to the research.microsoft.com subdomain. In this case, the name server for the parent domain does not control the records for the research.microsoft.com subdomain, but it does control the records for the parent and the dev.microsoft.com domain. A server called ns1.research.microsft.com holds all the RRs for the research.microsoft.com domain.

Creating different zones of authority can be an efficient way of optimizing zones that contain a great many RRs. However, creating zone delegations can involve a security trade-off in that different administrators might be responsible for the servers that are authoritative for the child domains.

start sidebar
Configuring & Implementing...
Configuring Delegations to Child Domains from Parent Domains

Knowing how to delegate authority to a child domain is important in implementing and maintaining a DNS infrastructure. To delegate authority from a parent domain to a child domain, the DNS servers that are authoritative for the parent domain must have NS records that identify the names of the DNS servers that are authoritative for the child domain, as well as the A records that point to the IP addresses of the DNS servers in the child domain. In our fictional example for the microsoft.com domain, the primary zone file for the microsoft.com domain would contain a set of records (NS and A records) to delegate authority for the research.microsoft.com zone:

research         NS        ns1.research.microsoft.com.  ns1.research     A         192.168.100.21

Note the lack of a trailing period after “research” on the left side of the NS and A records. The lack of a period indicates that this name is unqualified; that is, it is not an FQDN, and the domain name microsoft.com is implicitly appended to the left side of the name.

There are a number of ways to delegate authority to a child domain. You can enter the records manually into the zone file or you can use the New Delegation Wizard, found on the context menu of the zone that is invoked when you right-click the zone in the DNS Microsoft Management Console (MMC). A third way to delegate authority is to create a stub zone for the child domains on the DNS servers that are authoritative for the parent domain. If you do this, you do not need to include records to delegate authority in the zone file of the parent domain. Stub zones are a new feature of DNS in Windows Server 2003. We will discuss their use in more detail later in this chapter.

end sidebar

In a standard DNS environment, authoritative servers are either primary or secondary servers. (Secondary servers are sometimes referred to as slave servers.) The primary server has an updatable version of the flat text file that contains the RRs for the domains for which it is authoritative. The primary server is the only server on which updates to the RRs can be made. The secondary server has a read-only copy of the zone file, which is updated by a process known as zone transfer.

The zone transfer process is usually initiated when the secondary server polls the primary server according to a predefined interval. The secondary server reads the SOA RR and compares the version number in the record with the version number in its SOA. If the version number is higher on the primary server, it will initiate the zone transfer process and copy the zone file over TCP port 53. It is possible to configure a primary DNS server to contact the secondary DNS servers on its list when there are changes to the zone file. It is also possible to use an incremental zone transfer (IXFR) to copy only the changes to the zone file, rather than the entire file, but this depends on whether the DNS servers support the IXFR protocol. If the secondary server is capable of IXFR transfers, it will request that the primary use IXFR to transfer the zone information; otherwise, it will request a standard zone transfer.

In a Windows 2000 and 2003 environment, it is also possible to store the zone information in AD rather than in flat text files. This configuration is known as an Active Directory-integrated zone. Updates can be made to any Active Directory-integrated zone; this is, Active Directory-integrated zones are primary DNS servers. Synchronization of Active Directory-integrated zones occurs through AD replication, rather than through the standard DNS mechanism of zone transfer. We will discuss these and other DNS server roles later in the chapter.

DNS Name Resolution Process

Distributing DNS RRs among many different zones and domains has an effect on the name resolution process that needs to occur for a DNS client to find a host name-to-IP address mapping. Let’s take the example of a client trying to connect to www.research.microsoft.com. The DNS client is configured to use another DNS server to perform recursion on its behalf. (Performing recursion simply means that the DNS server will issue iterative queries to other DNS servers and accept referrals from these servers until it receives a positive or a negative response, and then forward that response to the DNS client.) The DNS client issues a recursive query to the DNS server; the DNS server subsequently issues a series of iterative queries to resolve the name. Figure 6.4 shows the process that occurs in order to resolve www.research.microsoft.com to the IP address.

click to expand
Figure 6.4: DNS Server Issuing Iterative Queries to Resolve an IP Address on Behalf of a DNS Client

Exam Warning

Don’t be confused about the difference between iterative and recursive queries. Iterative queries occur when a DNS resolver asks a DNS server to perform the work of finding the answer for it. An analogy will be helpful to illustrate the concept of iterative and recursive queries. You ask your class instructor a question about AAAA records. Your instructor says he doesn’t have the answer but will find out. After doing some research and asking other people for advice and direction, he finds the answer and relays it to you. In the meantime, you wait for either an informative answer to your question or a negative response. Your instructor has performed a series of iterative queries to find the answer. You have issued only a single recursive query and simply waited for a positive or negative response.

The DNS client requests that dns1.shinder.net use recursion to return an answer to its query for the IP address of www.research.microsoft.com. (By default, both the DNS client and the DNS server service are configured to support this arrangement.) The DNS server first checks to see whether it can answer authoritatively from locally configured zone information. If it doesn’t have the zone information, the DNS server then checks its cached information to see if it has previously answered the same query. If it doesn’t have this information in cache, it then begins the process of recursion to find the answer for the DNS client.

The process of recursion begins with the contacting of the root DNS servers, which are authoritative for the top-level domain on the Internet. To find these authoritative servers, the DNS server will consult its root hints file, which is a list of RRs that provides information about the name servers that are authoritative for the top-level domain on the Internet. Windows 2000 and Windows Server 2003 servers will automatically install this file when you install the DNS service on your server, in most circumstances. You can also get the most current version of this file from ftp://rs.internic.net/domain/named.root.

Note that the root hints file is present on the DNS server only if the DNS server has not itself been configured with a root, or ., zone. If this zone is present on your DNS server, it means that this server is the highest level of authority for the root domain, and the server will not be able to perform DNS queries on the Internet. If you use the Dcpromo utility to install and configure the DNS server as a prerequisite for installing a domain controller, that utility will automatically configure the DNS server with the . zone. If you wish to use the root hints file on this server to perform recursion on the Internet, you will need to first delete the . zone from the DNS server.

Note

The root hints file is found in the %systemroot%\system32\dns\cache.dns file. By default, this file is prepopulated with the root hints for Internet servers that are responsible for resolving top-level domain names and delegating authority to second-level domains. This file can be modified directly or from the Root Hints tab of the DNS server property pages. On servers that are configured with a root, or ., it is recommended that this file be removed completely. In a Windows environment where you have deployed a private root, DNS servers will learn of the servers hosting the root zone and automatically update this file, as long as the TCP/IP properties are configured with the IP addresses of the root servers. You can also modify the file to reflect your DNS infrastructure.

In this example, the root DNS server is not authoritative for the .com domain, but it does contain NS records for the servers that are authoritative for this domain. It sends this information back to dns1. Then dns1 contacts a server that is authoritative for the .com domain. Again, because authority for the microsoft.com domain has been delegated to other servers, it sends the name server referral information for the microsoft.com domain to dns1. Then dns1 contacts a name server that is authoritative for the microsoft.com domain. If this server had also been authoritative for the research.microsoft.com domain, it would respond with the IP address of the requested host. However, because authority for this subdomain has been delegated to other name servers, it sends name server referral information back to dns1, which is finally able to contact an authoritative server and receive a positive reply to its query for the IP address of www.research.microsoft.com. Once it finds this information, dns1 sends the positive reply containing the IP address information to the DNS client, which is then able to connect to the Web site.

This recursion process assumes that no information about the FQDN for www.research.microsoft.com is cached on either the DNS client or dns1. However, over a period of time, dns1 would cache information about the domain namespace and would learn the IP addresses of authoritative name servers for domains and hosts on the Internet, thereby eliminating steps and speeding up the process of name resolution. But even without cached information, DNS host name resolution is very efficient, because it will normally use small UDP packets (512 bytes), unless the response is too large to be contained in a single UDP packet; in which case, TCP will be used.

In our example, three kinds of common responses to DNS queries are used:

  • An authoritative answer This means that a response is sent from a server that is authoritative for the record of domain.

  • A referral answer This means that an answer was sent back to the DNS requester that contained information not originally requested to provide hints to find the answer. For example, if the request is for an A RR, the DNS server might return a CNAME or an NS record in response to the query to help the requester find the answer.

  • A positive answer This means that a positive response to the query is sent to the requester.

start sidebar
New & Noteworthy...
Using Extension Mechanisms for DNS (EDNS0) to Change
the Default Size of UDP Packets Used by DNS

The original RFC for DNS (RFC 1035) limits the size of UDP packets to 512 bytes. However, Windows Server 2003 implements a more recent standard for UDP packet size (RFC 2671) that allows the administrator to configure a larger allowable UDP packet size for responses to DNS queries. When EDNS0 is configured on the DNS requester to allow UDP packets that are larger than the default size, the DNS requester sends this information to the DNS server in a query that contains an OPT RR that advertises the maximum size of the UDP packet to use in the response. When the DNS server receives this information, it will truncate the packet at the maximum allowable size specified in the OPT RR. If this information is not present, the DNS server assumes that the DNS requester does not support packets larger than 512 bytes.

Care must be taken when configuring support for EDNS0 to ensure that the UDP packet does not exceed the maximum transmission unit (MTU) packet size of any device, such as a router, that the request and response must traverse. To change the UDP packet size and EDNS0 cache settings, you must modify the Registry. For more information about EDNS0, see RFC 2671 at www.rfc-editor.org/rfc/rfc2671.txt.

end sidebar

A fourth possible response is a negative answer. This means that the authoritative server does not have a record for the queried name, or that it does have a record for the queried name, that is a different RR type than specified in the query.

Regardless of the answer that is returned, the results are cached so that subsequent DNS queries can be answered with nonauthoritative responses from name servers that contain the cached information. With the exception of a negative answer, the results are cached according to the value specified for the minimum TTL in the authoritative zone’s SOA RR; that is, the authoritative name server controls the TTL of the RR for cached records on DNS requesters. In the case of a negative response, this information is also cached for a period of five minutes by default to prevent unnecessary consumption of resources if the name is queried again. The period for caching negative responses is relatively short to allow the query to be resolved if the RR becomes available in the future. Negative caching is a DNS standard that is documented in RFC 2308.

It is possible to set up caching-only DNS servers. These are DNS servers that contain no zone information and function only to provide support for the recursion process for DNS clients. We will discuss the various DNS server roles later in this chapter.

Forward versus Reverse Lookup Zones

In most of the preceding discussion, we have focused on forward lookup zones. These are DNS data files that provide answers to forward queries that ask for the IP address of a particular FQDN. However, reverse lookup zones are also widely used to provide answers to reverse queries that ask for the FQDN of a particular IP address. For example, if you wanted to find the FQDN associated with a particular IP address, you would perform a reverse lookup against a reverse lookup zone.

To handle reverse lookups, a special root domain called in-addr.arpa was created. Subdomains within the in-addr.arpa domain are created using the reverse ordering of the octets that form an IP address. For example, the reverse lookup domain for the 192.168.100.0/24 network would be 100.168.192.in-addr.arpa. The reason that the IP addresses are inverted is that IP addresses, when read from left to right, get specific; when the IP address starts with the more general information first. FQDNs, in contrast, get more general when read from left to right; the FQDN starts with a specific host name.In order for reverse lookup zones to work properly, they use a special RR called a PTR record, which provides the mapping of the IP address in the zone to the FQDN.

Reverse lookup zones are used by certain applications, such as NSLookup (an important diagnostic tool that should be part of every DNS administrator’s arsenal). If a reverse lookup zone is not configured on the server to which NSLookup is pointing, you will get an error message when you invoke the nslookup command.

start sidebar
Head of the Class...
Security Considerations for the Presence of a Reverse Lookup Zone

Being able to make NSLookup work against your DNS servers is not the most important reason why you should configure reverse lookup zones. Applications on your internal network, such as DNS clients that are trying to register PTR records in a reverse lookup zone, can “leak” information about your internal network out to the Internet if they cannot find a reverse lookup zone on the intranet. To prevent this information from leaking from your network, you should configure reverse lookup zones for the addresses in use on your network.

For more information about security and reverse lookup zones, see http:// support.microsoft.com/default.aspx?scid=kb;EN-US;q259922. Note, however, that the information regarding the name of the blackhole servers in this article is out of date. The Internet Assigned Numbers Authority (IANA) has set up two blackhole servers, blackhole-1.iana.org and blackhole-2.iana.org, to handle the bogus addresses from private networks that leak onto the Internet. For more information on this topic, see Kent Crispin’s FAQ at http://archives.neohapsis.com/archives/ incidents/2002-09/0059.html.

end sidebar

Exercise 6.01: Installing Windows Server 2003 DNS Service and Configuring Forward and Reverse Lookup Zones

start example

The exercises in this chapter require that you install Windows Server 2003. You can download a 180-day evaluation copy of Windows Server 2003, Enterprise Edition, from www.microsoft.com/windowsserver2003/evaluation/trial/evalkit.mspx . If you wish to preserve your current operating system, you can install Windows Server 2003 in a VMware virtual machine, which allows you to emulate a PC on which to install Windows Server 2003. You can download a 30-day evaluation copy of VMware Workstation 4.0 from www.vmware.com/vmwarestore/newstore/wkst_eval_login.jsp.

This exercise assumes that a single Windows Server 2003 server is installed as a stand-alone server and is not a member of any domain.

Before you install the DNS service, you might wish to ensure that the domain name in the FQDN for the computer name matches the domain name of the DNS forward lookup zone you plan to install. It is not a requirement that the domain name of the FQDN and the DNS forward lookup zone match. However, if they do match, you will find that Windows Server 2003 adds the appropriate records to the forward lookup zone for the DNS server. To change the FQDN for the computer, follow these steps:

  1. On the Windows Server 2003 desktop, right-click the My Computer icon and select Properties from the context menu.

  2. Select the Computer Name tab, and then click the Change button.

  3. In the Computer Name Changes property pages, click the More button.

  4. In the DNS Suffix and NetBIOS Computer Name property page, change the primary DNS suffix to tacteam.local (or a name of your own choosing) and click OK. Reboot the computer when prompted.

Another prerequisite for installing DNS is that your TCP/IP properties should be configured with a static IP address and the primary DNS settings should be configured to point to the address of the computer on which you are installing DNS. To configure TCP/IP properties, follow these steps:

  1. On the Windows Server 2003 desktop, right-click the My Network Places icon and select Properties from the context menu.

  2. In the Network Connections folder, right-click the Local Area Connection icon and select Properties from the context menu.

  3. Highlight TCP/IP, and then select Properties.

  4. In the TCP/IP properties page, configure a static IP address, and then configure the primary DNS server settings to point to the IP address of the server. (For the examples in this chapter, we are using addresses on the 192.168.100.0/24 network.)

After you have configured your computer with the appropriate FQDN and IP address, you can install the DNS service. There are a couple of ways you can do this. You can install the DNS service through the Manage Your Server page that appears when you first log on to your Windows Server 2003 computer, or you can install the service through Control Panel | Add/Remove Programs | Windows Components. In this exercise, we will install the service through Control Panel. To install the DNS service, follow these steps:

  1. Select Start | Control Panel | Add or Remove Programs.

  2. Select Add/Remove Windows Components.

  3. In the Windows Component Wizard dialog box, scroll down the list of Windows components, highlight Networking Services, and then click Details.

  4. In the Networking Services dialog box, click Domain Name System (DNS) to place a check mark in its box, and then click OK.

  5. If prompted, insert the Windows Server 2003 source CD to provide the installation files for the DNS service, or enter the name of a network path to the installation files.

The DNS service is now installed on your Windows Server 2003 computer. By default, the DNS server is installed with the root hints file and will resolve queries to the Internet. If you have an Internet connection, you can verify this by using the browser on the Windows Server 2003 server and connecting to a Web site. (Alternatively, you can verify this by performing the test labeled Perform a recursive query to other DNS servers, which you can find in the DNS console on the Monitoring tab of the properties of the DNS server.)

Next, we cover the steps to add a forward lookup zone. We begin by creating a standard primary forward lookup zone:

  1. Navigate to the DNS console by selecting Start | Programs | Administrative Tools | DNS. (You can also invoke the DNS console through the Manage Your Server page that is displayed when logging on to the Windows Server 2003 computer.)

  2. In the DNS console, right-click Forward Lookup Zones and click New Zone in the context menu.

  3. The New Zone Wizard appears. Click Next. Ensure Primary Zone is selected as the zone type and click Next.

  4. Type in tacteam.local as the zone name, and then click Next. (You can also type in a domain name of your own choosing. For ease of configuration later, it should match the domain name portion of the FQDN of the computer name.)

  5. Select the option to Create a new file with this name. (A filename has already been created based on the domain name.) Click Next.

  6. On the subsequent page, click Next again to accept the default setting not to allow dynamic updates, and then click Finish.

We now need to verify the records in the new zone. To do this, perform these steps:

  1. In the DNS console, expand Forward Lookup Zones, and then click the zone you just created.

  2. Examine the contents of the zone on the right side of the window. You should see three records: an SOA, an NS, and a Host (A) record. If you are missing any of these records, the reason is that the domain you chose to create did not match the domain in the FQDN for the computer name, or the TCP/IP configuration was not pointing to the configured IP address for the primary DNS.

We now can create a reverse lookup zone. The reverse lookup zone is used to resolve IP addresses to names. In addition, if we want to use NSLookup to query the DNS server, we need a reverse lookup zone containing a PTR RR that points to the authoritative DNS server in the zone. The domain name will be based on the IP subnet and the suffix, in-addr.arpa. In these exercises, we are using the subnet 192.168.100.0/24, so the reverse lookup domain will be 100.168.192.in-addr.arpa.

  1. In the DNS console, right-click Reverse Lookup Zones and click New Zone in the context menu.

  2. Follow the previous steps for creating a forward lookup zone. However, you will need to type the network ID of your network when prompted. (The New Zone Wizard will create the appropriate domain name based on your network ID, so do not change the order of the octets in your address. If you are following the setup for these exercises, you should type 192.168.100 as the network ID in the Wizard.)

After you have created the reverse lookup zone, examine the records that are created in it. You should see only two records: an SOA record and an NS record. Open a command prompt and invoke the nslookup command. You should see an error message, such as the following:

*** Can’t find server name for address 192.168.100.21: Non-existent        domain   Default Server:  UnKnown   Address:  192.168.100.21

To correct this situation, we need to add a PTR RR for the DNS server. To do so, follow these steps:

  1. Right-click the reverse lookup zone you just created and select New Pointer (PTR) from the context menu.

  2. In the New Resource Record dialog box, enter the host ID for the DNS server (the last number in the IP address), click Browse, and navigate to the A record for your DNS server in the forward lookup zone you created previously.

  3. Finish creating the record. You should now have a PTR record in addition to the NS and SOA records. To verify the record is correct, invoke the nslookup command from a command prompt. You should see the name of the DNS server (instead of “Unknown”) in the output.

Now that you have installed a DNS server and have created forward and reverse lookup zones, you will be able to explore and examine DNS server settings. You should use the New Delegation Wizard to create a delegation of authority to a subdomain of the domain you just created. To create a delegation of authority from a parent domain, right-click the forward lookup zone for the parent domain and select New Delegation. Follow the steps presented by the Wizard.

It’s obviously better if a DNS server that is authoritative for the subdomain actually exists, but if this is not the case, you can still create the records used to delegate authority. If you are able, you should install a second Windows Server 2003 server to further explore the features of DNS, such zone transfers, stub domains, and so on. This server can be installed on a virtual machine using VMware; you can run multiple virtual machines, all of which can communicate with one another on the network.

end example

Designing a DNS Namespace

EXAM 70-293 OBJECTIVE 2.7.1

Designing a DNS namespace is a critically important function for any business that relies on both the public and the private identities provided by the DNS namespace(s) for interaction with its customers and for the smooth and secure operation of its network. You should take some of the following considerations into account:

  • Uniqueness Domain names on the Internet must be unique. To guarantee uniqueness of the public domain namespace, the public domain must be registered with the Internet Corporation for Assigned Names and Numbers (ICANN) through one of many authorized registrars. Although it is not a requirement that your internal domain namespace be unique, it is prudent to ensure its uniqueness.

  • Integration and interaction of public and private DNS namespaces It is possible to use the same or different DNS namespace(s) for the public and private networks. Each of these alternatives provides different challenges. To separate the public and private zones requires both planning and administrative effort. One method of separating the public and private namespaces is to base the DNS namespace for AD on the internal network on a delegated subdomain of the public domain. Another method involves choosing a different domain suffix, such as .local instead of .com, for the private namespace that is the root of AD.

  • Security Designing a DNS namespace should take into account the security requirements and configuration of your network. For example, it is extremely inadvisable to allow any RRs that are specific to your internal network to be publicly available through DNS queries. You should set up separate name servers to respond to queries for the IP addresses of the organization’s Internet hosts, such as Web and mail servers. Deploying a private root zone can also help to enhance the security of your DNS infrastructure. Additionally, you need to consider firewall placement and access rules when designing the DNS namespace. Does the security organization’s security policy allow or restrict access from the Internet to internal DNS servers? In addition to considering who can query DNS servers, it is important to consider who can update RR records in the authoritative zones and how those records are updated. For example, you might not wish to allow dynamic updates in the top-level domain, but you might want to allow updates in the child domain. You would design your namespace accordingly.

  • Administration The design of the DNS namespace will affect administration. For example, using the same domain namespace for both the private and the public networks will require, at a minimum, a split DNS configuration, where two name servers (one that is authoritative for the public RRs and one that is authoritative for the private RRs) will need to be implemented and maintained. In this scenario, special configurations might need to be implemented to allow users on the corporate network to connect to the organization’s public Web servers.

Choosing the Parent Domain Name

When choosing the parent domain name to support your organization’s business and infrastructure, consider whether to use or acquire an Internet domain name that is registered to your organization. If the name you choose is for use on your internal network only, you can use any name you want. However, although it is not a requirement that domain names used on your internal network be unique, it is a good idea to ensure that they are.

The best way to ensure the use of a unique domain name for the internal network is to base the domain name on one your company has registered for use on the Internet. If your organization has not registered a domain name or its currently registered name is not acceptable for use on the internal network, you should register a new domain name with an ICANN-accredited registrar.

Note

You can find a complete list of ICANN-accredited domain name registrars at www.icann.org/registrars/accredited-list.html.

Depending on the nature of your organization, you will want to register a domain name that has a top-level domain (TLD) name like .com, .net, .edu, or .org. You can find a complete list of top-level domains supported by ICANN, along with a description of their appropriate uses, at www.icann.org/tlds/. Sometimes, organizations will register their domain names in as many top-level domains as possible to prevent others from taking advantage of any brand recognition that the chosen domain name might possess. For example, in addition to registering a name that has the form mydomain.com, you might also wish to register mydomain.net, mydomain.biz, mydomain.org, and so on. Furthermore, organizations that have a prominent presence on the Internet may also register common misspellings of the domain name to ensure connectivity for users who mistype the name in their browsers or e-mail clients. You should try to find a domain name that you can register with as many common top-level domains as possible. For example, if another company has already registered mydomain.com, but not mydomain.net, you might wish to expand your search and find a new domain for which you can register a .com extension. Many users will try a .com extension before trying a .net or other extension to reach your organization’s Web servers.

Before you can register a name, you need to determine if it is unique. Most domain name registrars provide a service for determining whether a name is available for registration. However, you can also use the Whois application on the InterNic.net Web site to determine if a name has been registered and who owns the name. You can find the Whois application at www.internic.net/whois.html.

When you register a domain name, you must provide the registrar with the IP addresses and host names of one or more DNS servers that will be authoritative for your zone. This DNS server can be located on your network or on the ISP’s network. In addition, many registrars offer a service whereby you can host your zone files on their DNS servers and manage these files directly (usually through a Web-based application).

Host Naming Conventions and Limitations

Regardless of the choice you make for the domain namespace of your internal and external networks, you should abide by host naming conventions and limitations. According to RFC 1123, “Requirements for Internet Hosts—Application and Support,” which defines naming standards for host names, the following US-ASCII–based characters are allowed:

  • Uppercase letters (A through Z)

  • Lowercase letters (a through z)

  • Numbers (0 through 9)

  • The hyphen (-)

Note that, according to RFC 1053, DNS resolution is supposed to be case-insensitive. For this reason, the Microsoft DNS service will “downcase” any uppercase characters that it encounters to lowercase (it is an optional requirement that case be preserved for use with DNS; to ensure maximum compatibility Microsoft does not implement the optional requirement for case preservation). In other words, all uppercase characters will be treated as lowercase characters.

The RFC 1123 standard is a relatively old one (created in October 1989) and places limitations on non-English organizations that might wish to use an extended or non-Roman–based character set for their names. Windows 2000 and Windows Server 2003 provide support for the more recent RFC 2181, which states that any binary string can be included in a DNS name. To allow for the use of more characters than are available with US-ASCII, Windows 2000 and Windows Server 2003 DNS servers provide support by default for UTF-8, which is a Unicode transformation format. Furthermore, Windows 2000 and higher client operating systems, such as Windows XP, are UTF-8 aware.

UTF-8 is a superset of extended ASCII and additionally provides support for UCS-2, which is a Unicode character set that allows for the use of the majority of the world’s writing systems. UTF-8 is backward-compatible with US-ASCII in that the binary representations of characters are identical between the two formats. However, because characters in some writing systems require more than 8 bits to represent a character, it is not possible to use character length as a means of calculating the maximum allowable length for a DNS name, which according to RFC 2181 is 63 octets per label and 255 octets per name. Because the last byte is used for the terminating dot of an FQDN, the maximum length of the name is 254 octets (bytes).

It is important to remember that not all DNS servers are UTF-8–aware. It is also possible to turn off UTF-8 support on individual Microsoft DNS servers by configuring the name-checking format in the DNS server property pages. Therefore, care must be taken in environments where not all name servers support UTF-8. In particular, when zone information is being transferred between UTF-8 and non-UTF-8 name servers, the zone can fail to reload on servers that do not support UTF-8 if the zone contains UTF-8 information.

Note

Even though Microsoft DNS provides support for UTF-8, it is generally a good idea, if possible, to limit host and DNS names to the US-ASCII character set supported by standard DNS to ensure maximum compatibility.

The Underscore Character

While it is legitimate to use the underscore character in NetBIOS names, the inclusion of this character in a host name is problematic in environments that use older DNS standards in which its use is prohibited. (The underscore character is allowed in domain names, however, so its use is legitimate in SRV records.) Support for UTF-8 guarantees that the underscore character can be used safely in Microsoft environments. In fact, the underscore is a reserved character that is used extensively in Microsoft DNS to identify SRV records as per RFC 2782. However, third-party standard DNS servers such as older UNIX BIND DNS servers, might not recognize host records that use the underscore. Consequently, host names, especially those used by Internet-facing servers, should not use the underscore character as a best practice. If you are upgrading a Windows NT 4 environment to Windows Server 2003, you might wish to consider changing the NetBIOS and host names of computers whose names include the underscore character before performing the upgrade.

DNS and Active Directory (AD)

AD was introduced with Windows 2000 and is improved and enhanced in Windows Server 2003. AD is an X.500-based directory service (similar to Novell Directory Services), which stores information about users, computers, printers, and other objects that compose your network. AD also provides a consistent naming convention for users and other objects, making it easy to locate and gain access to these objects.

In addition to providing centralized control of resources and a means to either centralize or decentralize resource management, AD provides a means of logically organizing objects into administrative units. The core administrative unit of AD is the domain. A domain is a collection of objects that are grouped together into a single administrative unit in a common database. These objects share common security policies (for example, minimum password length). Furthermore, the domain itself is a unit of replication within AD among all the domain controllers that are members of a particular domain. There is a very close relationship between DNS and AD: the AD domain name is also the DNS domain name, which is stored in a DNS zone.

Domains are grouped into a logical hierarchy referred to as a domain tree. This logical hierarchy mirrors the hierarchy of the DNS namespace. When a new domain is added to the domain tree, it becomes a child domain of the parent domain to which it is added, as is the case with the DNS namespace. Furthermore, the DNS name for the new child domain is contiguous with the parent domain; that is, both the parent and child domain are part of the same DNS namespace.

Let’s take the example of a root Windows Server 2003 domain that is named shinder.net. We add a child domain named corp to the parent domain. The resulting unique FQDN for the child domain is corp.shinder.net.

AD can comprise more than one domain tree. The resulting group of domain trees is called a forest. The domain trees do not share a contiguous DNS namespace. However, they do share trust relationships and a common AD schema, that is replicated to domain controllers throughout the forest. If there is only one domain tree in the forest, the subdomains in the tree are child domains of and contiguous with the forest root domain, which is the first domain controller installed into AD. The forest root domain and its child domains form another administrative and security boundary.

If there is more than one domain tree in the forest, the forest has a disjointed DNS namespace. That is, the namespace for the entire forest is not contiguous. Disjointed name spaces may require special DNS configurations in order to ensure proper name resolution throughout the forest. For example, if you have a private root zone, you need to ensure that you add delegations for your top-level domains to the root zone so that DNS requesters can find the servers that are authoritative for the appropriate domain. Alternatively, you might need to configure secondary servers and conditional forwarders to ensure name resolution.

Figure 6.5 shows the relationship between an AD forest and domain trees. Note the similarity of the AD domain names with the DNS namespace.

click to expand
Figure 6.5: An Active Directory Forest with Two Domain Trees

As noted earlier, AD has a close relationship with DNS. AD is, in fact, dependent on DNS, which is fundamental to its operation. In a Windows 2000 or Windows Server 2003 network, hosts must be capable of resolving names to IP addresses using DNS.

As a prerequisite to installing AD, you must first have a DNS infrastructure in place on your network and your TCP/IP stack must be configured to use an appropriate DNS server. The DNS server must be authoritative for the domain name of your AD and must be able to support a special kind of RR known as an SRV record, which provides information about well-known network services and replaces the legacy WKS record. By default, Windows 2000 and Windows Server 2003 DNS servers provide support for these records. Other DNS servers, such as those that implement the most recent version of BIND (BIND 9 as of this writing), might support these records as well, but this needs to be confirmed beforehand if you are using something other than Microsoft DNS.

The DNS server should also be capable of supporting the following:

  • Dynamic DNS (DDNS) updates DDNS is a protocol that allows servers and DNS clients to update DNS records in the master zone file. Although it is not a requirement that the DNS server support DDNS, it is highly recommended that it do so. Support for DDNS eliminates a considerable amount of administrative work that must be performed in the form of manually adding DNS records to support AD and the network infrastructure in general. Windows 2000 and Windows Server 2003 DNS servers support DDNS, as does BIND 9.

  • Incremental zone transfers (IXFR) When a zone file on a master DNS server is updated on a secondary DNS server, the entire file is transferred over TCP port 53 using the AFXR protocol. To eliminate unnecessary traffic associated with zone transfers, the IXFR protocol allows for the transfer of specific updated records, rather than the entire file, between master and secondary servers. The Microsoft DNS service supports IXFR, as do BIND versions 8 and 9.

If an appropriate DNS server is not available when you install your first Windows Server 2003 domain controller, the Dcpromo.exe application will prompt you to install and configure the DNS service on the computer you are promoting to a domain controller.

If you choose to install DNS through the Dcpromo.exe application, you should note that a . (root) zone will also be installed at the same time. If this zone is present on the DNS server, you will not be able to use the DNS server to resolve queries for hosts in zones for which the server is not authoritative. That is, you will not be able to use this DNS server to resolve queries on the Internet. You can correct this situation by deleting the root zone and either configuring the DNS server as a forwarder or adding the root hints file.

AD is capable of storing DNS zone information in the form of Active Directory-integrated zones. We will discuss this feature in more detail later in this chapter.

Note

When you install a domain controller, a file called netlogon.dns is created in the %systemroot%\system32\config folder. This file contains the SRV and other RRs required to support AD DNS resolution. You can use this file to assist in populating the zone file of a DNS server that does not support dynamic updates.

Supporting Multiple Namespaces

When you plan to use DNS for name resolution on your intranet and also plan to have a presence on the Internet, you need to consider how to support one or multiple name spaces. Assuming that you have a publicly registered Internet domain name and wish to base the internal domain name on this one, you have three choices for the selection of your internal domain name:

  • Same domain name for external and internal use In this scenario, if your publicly registered domain is mydomain.com for use on the Internet, you use mydomain.com as your internal domain name for your intranet. This configuration requires that you manage separate DNS servers for your internal network and the external network that are both authoritative for the same domain name. This configuration is sometime referred to as a split DNS. However, the internal DNS servers will contain RRs that are specific to your internal network and possibly contain RRs for your publicly available Web and mail servers. The DNS servers that are authoritative for the internal network should not be available to external clients. Depending on your security requirements and network configuration, you might find it necessary to maintain a copy of your Internet-facing servers such as your Web server on your intranet for use by your internal clients. The external DNS server that is authoritative for the domain will contain RRs for your publicly available Internet-facing servers only (such as the Web and mail servers) and will not contain RRs for your internal network. This model increases the administrative effort for managing DNS records and security, so it is not a recommended solution. However, a key advantage is that your organization’s users do not need to remember different domain names for your organization’s externally available servers.

  • Different namespace for internal use In this scenario, you would use either a completely different name for the internal name of the intranet or use a domain namespace based on the registered domain name but with a different top-level domain suffix, for example, mydomain.local. Microsoft recommends using a namespace based on a registered domain name in the (unlikely but possible) event that two organizations that are using the same AD name merge. If the domain name is registered, it must be unique by definition. A key advantage of this approach is that it provides you with a unique and separate namespace for use on your internal network. With this configuration, the administrative effort required to manage the domain namespace is minimized, compared to using the same domain name for internal and external use. Also, security is enhanced and easier to manage for the following reasons:

    • The internal namespace is not exposed in the form of NS and A records used to delegate authority to the child domain in the parent domain.

    • The internal domain namespace is not reachable by clients on the Internet.

    • It is not necessary to transfer zone information between the publicly available DNS servers to internal DNS servers that might function as primary masters or secondary servers for the parent domain zone file.

      A disadvantage of this option is that it requires that you manage two separate DNS namespaces, increasing administrative complexity. For example, using an unrelated internal domain name might require you to register this name with ICANN. Furthermore, using an unrelated internal domain name might cause confusion among users in your company.

  • Delegated subdomain for internal use In this scenario, your internal domain namespace begins at a subdomain of the publicly registered domain namespace. For example, if your domain name is mydomain.com, you would use something like internal.mydomain.com for your internal namespace on your intranet. To support this configuration, you need internal DNS servers that are authoritative for the subdomain and are available only to your internal network (that is, the child domain namespace is not accessible to external users). Your internal clients, however, would be able to gain access to both the internal and external DNS servers. This approach has a number of advantages:

    • Administrative effort to maintain the DNS namespace is minimized.

    • Both your internal and Internet-facing servers share the same contiguous namespace, making it easier for users to connect to these resources.

    • Any DNS records used for AD are isolated in the child domain and its subdomains. The delegated child domain becomes the forest root domain for AD.

Disjointed Namespaces

Many companies have needed to deploy a disjointed namespace; that is, they design their DNS infrastructure to support two or more noncontiguous namespaces. For example, because of the high level of trust required for Domain Admins in a forest, many companies have deployed multiple forests to meet strict security requirements. In other cases, because of mergers and acquisitions, companies have needed to create Windows NT-style trusts between individual domains in the separate forests to enable resource access.

In Windows Server 2003, it is now possible to create to create one-way or two-way, cross-forest transitive Kerberos trusts. A two-way transitive trust simplifies resource management because it automatically enables trusts between all domains in the separate forests. This feature, along with complex business needs to deploy disjointed namespaces for separate business units, will make disjointed namespaces more common. Implementing a stable DNS infrastructure to support DNS resolution for a disjointed namespace creates challenges for the DNS administrator. For example, the DNS administrators in the separate forests might need to host secondary zones for the primary zones in the remote forests. The Windows Server 2003 DNS service includes two new features that make it easier to support disjointed namespaces:

  • Conditional forwarding Makes it possible to configure a DNS server to automatically contact predefined DNS servers based on the domain name in the query request. Thus, when a DNS server encounters a query request for name resolution for resources in a separate namespace, it can forward this query to a particular, predefined set of DNS servers.

  • Stub zone A concept borrowed from implementations of BIND. The stub zone is a special kind of secondary zone and consists of only a subset of records from the primary zone of the child domain: the SOA, NS, and A records that identify the DNS servers that are authoritative for the child domain. The NS and A records (sometimes known as glue records) are updated on the DNS server hosting the stub zone based on the refresh interval specified in the SOA record. A DNS server hosting a stub zone can respond to recursive queries and contact the DNS servers that are authoritative for the child domain, or it can respond to iterative queries and provide referrals to the DNS servers that are authoritative for the child domain.

When a DNS server hosts a stub zone for another domain, the server can contact the authoritative servers for the domain directly when it receives a request to resolve a name query, helping to reduce DNS name query traffic and the load on the primary DNS server. Stub zones are useful in situations where authority is delegated to DNS servers in a child domain from a parent domain, such as when you are deploying your own internal root (discussed in the next section) and need to support a disjointed namespace. Stub zones remove the need to manually maintain glue records for the child domain in the parent domain. If a DNS administrator changes the NS or glue records in the child domain, this information will be updated in the stub zone, making it unnecessary for the DNS administrator in the parent domain to manually update records used to delegate authority.

These automatic updates serve to prevent a specific and common problem in a DNS infrastructure, which is known as lame delegation. A lame delegation occurs when the NS and glue address records used to delegate authority from a parent to a child domain are incorrect and prevent DNS servers from contacting DNS servers that are authoritative for a child domain.

Note

Because a stub zone is a kind of secondary zone, it is important to ensure that the zone transfer security is configured appropriately in the authoritative subdomain so that the stub zone can be replicated to the parent domain that is hosting the stub zone. By default, when you set up a primary zone, the zone transfer security allows zone transfers only to secondaries listed on the Name Servers tab. You will need to change these settings to allow zone transfers to occur to specific IP addresses, including those for the DNS servers that are configured to host the stub zone and are not listed in the Name Servers tab.

Exam Warning

You should know how to support disjointed namespaces and how to prevent problems arising from improperly configuring delegations of authority to other domain servers, because these are important issues in a Windows DNS infrastructure. You should be prepared for exam questions that require a thorough understanding of the challenges and solutions involved in supporting a disjointed namespace, such as the use of stub zones and conditional forwarding (which can be used as an alternative to stub zones). Additionally, you should know how to manually delegate authority from a parent to a child domain.

Deploying an Internal DNS Root Zone

In considering your DNS infrastructure, you should determine whether it is necessary or desirable to deploy an internal DNS root zone (the . zone). When you deploy a private root zone, you create a configuration whereby your DNS servers are authoritative for the entire DNS namespace. The private root zone contains only delegations to your internal top-level domains. Consequently, these DNS servers will not perform DNS name resolution on the Internet. If you wish your DNS servers to perform name resolution outside your organization (for example, to servers belonging to a partner or merged organization), you can add delegations from your root zone and top-level domains in the form of NS and glue A records to external DNS servers that are authoritative for other domains. In this situation, it might be advantageous to deploy a stub zone on dns1.shinder.local so that the NS and glue A records for DNS servers in the tacteam.net domain are automatically updated.

A primary advantage of this approach is enhanced security. Your DNS clients and servers that are authoritative for your DNS zones never send DNS information on the Internet. Furthermore, for large and complex networks that span WAN links, deploying a private root zone helps to simplify your DNS infrastructure.

If Internet name resolution is a requirement on your network, you might not be able to deploy a root zone. However, if your client computers are capable of using proxy servers such as ISA Server 2000, client computers can access Internet resources through the proxy server, which will perform name resolution on their behalf. The proxy server and computers that cannot use the proxy client software need to be configured to use separate, internal DNS forwarders or other DNS servers for Internet name resolution.

Figure 6.6 shows a possible deployment of an internal private root zone in combination with a proxy server to allow connectivity to external Web sites for client PCs. The figure also shows a delegation to a disjointed namespace (tacteam.net) to allow an internal DNS server to resolve host names on the tacteam.net network. Note that dns1.shinder.local does not perform Internet name resolution for client PCs. The ISA Server contacts a DNS server capable of performing name resolution on the Internet. However, dns1.shinder.local, by virtue of a name server delegation, performs recursive DNS resolution for hosts in the tacteam.net network.

click to expand
Figure 6.6: Deployment of a Private Root Zone

In the example in Figure 6.6, a considerable amount of DNS name resolution traffic can cross a WAN link between the shinder.local and the tacteam.net networks. To reduce this traffic, you can host a secondary zone for tacteam.net on dns1.shinder.local and host a secondary zone for shinder.local on dns1.tacteam.net. In fact, in order for dns1.tacteam.net to perform name resolution for hosts on the shinder.local network, you must either host a secondary zone for shinder.local, or use some other configuration, such as conditional forwarding to make it possible for this name resolution to occur.

General Guidelines for Internal Domain Namespaces

In deciding which approach is best for your organization, take into account a number of complex factors, such as the presence of firewalls and proxy servers, client software, and the number and location of DNS servers under your control. Regardless of the approach you take, you should follow some common-sense guidelines:

  • Keep it simple. Don’t create a DNS infrastructure with too many subdomains (limit the number to five or fewer subdomains). As a corollary to this, try to limit the number of authoritative zones to a minimum number; don’t create separate zones of authority for individual subdomains, unless it is necessary.

  • Use your own company or product names, not those of another company.

  • Register the domain names used by your company and base internal names on registered names.

  • Avoid acronyms and geographical names that might not be easily understood.

  • Don’t base names on things that are likely to change, such as business units or divisions that can disappear or be renamed during the next company reorganization.

  • Don’t repeat names that occur on the Internet. For example, don’t create a top-level domain name that already exists on the Internet, such as .ca, .biz, and so on. This will cause problems for external name resolution.

  • Consider security and ease of administration—these goals might be mutually exclusive and require trade-offs.

  • Use host names that are unique across your entire DNS infrastructure (keep in mind that DNS is not case-sensitive).

  • Develop a convention for naming internal computers that is consistent, informative, and easily understood and remembered.

  • If possible, use US-ASCII characters only for host and domain names and consider changing any NetBIOS computer names to ensure conformity with the US-ASCII character set.

  • If you’re using AD, make sure that the primary DNS suffix on your computers matches the AD domain name.

Planning DNS Server Deployment

Once you have determined your requirements for your DNS namespace and host names and have determined the number of subdomains, you must plan for the deployment of the DNS infrastructure on DNS servers. The goal of this planning is to ensure maximum availability, fault tolerance, currency of updated DNS records, and security, while at the same time minimizing the amount of traffic associated with DNS query and zone transfer traffic. The size and placement of zone files in your DNS topology will have a direct bearing on these considerations. Your network topology also has a direct bearing on these considerations. For example, the presence of WAN links connecting remote subnets and the available bandwidth on those links will affect the deployment of your DNS infrastructure.

Planning the Number of DNS Servers

On a simple network consisting of a single zone and relatively few hosts, you should try to deploy a minimum of two DNS servers. With two DNS servers, you ensure fault tolerance in the event that one DNS server fails or is temporarily removed from the network for maintenance.

On larger, more complex networks, you should deploy at least two DNS servers for each zone of authority you administer on your network. To reduce administrative complexity, keep the number of DNS servers you deploy to a minimum, while at the same time ensuring a high level of availability, fast query response times, and currency of records.

To reduce administrative complexity and to ensure fast query response times and fault tolerance, you can configure servers in a variety of roles. For example, you can configure conditional forwarders and other types of caching-only servers and use these in combination with DNS servers that are authoritative for particular domains. We will discuss forwarders and other DNS server roles later in this chapter.

To determine the number of DNS servers you need, you should keep the following guidelines in mind:

  • A Windows Server 2003 DNS server on a 700 MHz Pentium III or higher computer with at least 256MB RAM can handle a large number of queries, more than 10,000 per second. If you experience slow response times, you can add additional DNS servers in the form of secondary servers or Active Directory-integrated zones.

  • A DNS server can host many different zones—as many as 20,000 small zones that contain only a few RR in addition to the SOA, NS, and glue address records. If there is excessive traffic related to recursive queries on the network as a result of delegation to other zones, DNS servers can be configured as secondary servers to remote primary servers.

  • If you have high-speed, reliable WAN links, you can use centrally located DNS servers to resolve queries for clients located in remote subnets.

  • If WAN links are not reliable, you can set up a secondary DNS server on the remote network to ensure availability of zone information.

  • Because DHCP servers and clients can automatically update DNS zone records using DDNS, zone replication traffic can become an issue on large networks even though Windows Server 2003 DNS supports incremental zone updates. If zone replication traffic across WAN links is a consideration, you can set up caching-only forwarders on the remote subnets to eliminate this traffic.

  • DNS servers can have multiple roles. For example, a DNS server hosting a primary zone for a particular domain can be configured as a conditional forwarder for other domains. Configuring a server as a conditional forwarder allows it to build up a cache of frequent queries for host name resolution, helping to reduce DNS-related traffic for particular domains.

    Note

    When determining how many DNS servers you need, consider the importance of fault tolerance. You should never have only a single DNS server; a minimum of two is recommended, so that you will have a backup in case the primary server goes down.

Planning for DNS Server Capacity

Your DNS deployment plan will also depend on the capacity of your DNS servers to respond to queries in a timely manner and their ability to load zone files into memory. The Windows Server 2003 Resource Kit provides the following typical recommendation for a Windows Server 2003 DNS server:

  • Pentium II computer running at 400 MHz

  • 256MB RAM

  • 4GB hard drive

  • Network adapter

This should be considered a minimum configuration for a DNS server. Adding RAM or using a faster processor will increase performance, especially if the DNS server must respond to many queries or load large zone files. Adding RAM can be particularly helpful for improving DNS performance. On startup, an authoritative DNS server loads its zone files into RAM. A typical RR consumes approximately 100 bytes of RAM, although the precise value is determined by the kind of RR; for example, an SRV RR consumes more RAM than an A RR. The DNS service itself uses 4MB of RAM without loading any zones. You can use these figures to determine the amount of RAM you need to support your zone files.

You should also keep in mind that a DNS server caches query results in RAM and can return nonauthoritative responses to query requests from its cache. (When a DNS server performs a recursive query on behalf of a DNS client, it stores the result in cache. The next time a DNS client makes a query request for the same record, the DNS server responds with a nonauthoritative answer from its cache.) The more RAM available for caching responses, the better the performance for returning nonauthoritative answers to DNS clients on the network.

The performance of the DNS server is also influenced by the number and types of DNS queries to which it must respond. Also, a multihomed DNS server (a DNS server with more than one network interface) that is listening on more than one IP address for DNS queries consumes additional resources. If the DNS server is also a primary server, the number of secondary servers that are polling for updates of the primary zone also have an effect on performance.

Another factor that has an effect on performance is whether the DNS server is processing dynamic updates to zone files and whether the computer is also configured as a domain controller and processing secure updates to the zone files.

Note

In some baseline tests that Microsoft performed on a single-processor Pentium III 733 MHz computer with 256MB of RAM and a 4GB hard drive, the DNS service was able to handle 9500 queries per second and 1300 dynamic updates per second with an average CPU utilization of 75 percent. The test machine had all unnecessary services removed and was not a domain controller.

To gain a more precise understanding of the resources required for your DNS server, you can gather information from the DNS-related Performance Monitor counters that are installed with the DNS service. We will discuss the topic of monitoring DNS performance in more detail later in the chapter.

Planning DNS Server Placement

Considering where to place DNS servers, you should try to eliminate single points of failure to ensure the availability of DNS and AD services. This means that for every zone in your control, you should have at least two authoritative servers for fault tolerance. All DNS clients should be configured with the IP addresses of primary and at least one alternate DNS server to contact for name resolution. The following guidelines might assist in determining placement of your DNS servers:

  • On segmented LAN environments, you should have at least two authoritative servers. These servers should be installed on different subnets.

  • On a WAN, you should try to ensure that an authoritative DNS server is installed at each geographic location.

  • If you are hosting an authoritative DNS for your Internet-facing hosts such as your Web and mail servers, consider hosting an offsite secondary DNS server at your ISP or on your domain name registrar’s network.

  • Consider which services will be unavailable if the router fails on your network segment. For example, if you have a small branch office that lacks a domain controller, users will not be able to use the services provided by AD if the router fails. In this case, there might not be any advantage to deploying a secondary server that is authoritative for your AD zones.

  • Consider zone replication traffic across slow WAN links. If zone replication traffic consumes too much bandwidth, consider using forwarding servers in the remote location.

Planning DNS Server Roles

In order to properly plan, implement, and maintain a DNS infrastructure for your network, you should have an understanding of the various DNS server roles that you can install and configure.

  • Authoritative name servers These are servers that contain the complete zone information for a domain and possibly its subdomains. Any domain will be served by one or more authoritative name servers. For purposes of fault tolerance and load balancing, there should be at least two authoritative name servers for each zone. In a Windows 2000 and Windows Server 2003 environment, it is possible to configure three types of authoritative name servers:

    • A primary master server is the authoritative name server that holds the updatable RRs. Any changes made to the zone file information must be made on this server. Unless you are using Active Directory-integrated zones, there is only one primary master DNS server for each zone of authority. A stand-alone server, member server, or Windows 2000 or Windows Server 2003 domain controller can be configured as a primary server.

    • Secondary servers, sometimes known as slave servers, hold a read-only copy of zone information that is transferred from the primary master server during a process known as zone transfer to ensure that RRs are synchronized between the secondary servers and the primary server. A zone transfer occurs in one of two ways. One way is for the secondary servers to poll the primary master server according to the refresh interval in the SOA RR and compare the version number in the SOA RR in the primary’s zone file with its own. If the number is larger, it will initiate the zone transfer process. Alternatively, the primary master server can notify the secondary servers on its list whenever updates are made to the zone file. A secondary server can also be configured to do zone transfers to other secondary servers. This configuration is used primarily in situations where the polling of the primary DNS server by a large number of secondary servers puts an unacceptable load on it. The trade-off lies in currency of records, since updates from the primary DNS server must travel through more than one secondary server before all the records are synchronized among DNS servers.

    • The Active-Directory-integrated configuration is specific to Windows 2000 and Windows Server 2003. Instead of zone information being stored in flat text files as is the case with the primary and secondary DNS servers, zone information is stored in AD. Rather than relying on the mechanism of zone transfers, AD replication is responsible for ensuring that zone information is synchronized among all the participating DNS servers. Another key advantage of using Active Directory-integrated zones is that any DNS server that stores the zone information can update RRs; that is, more than one DNS server can update the zone information. Secondary zones cannot be stored in AD. Active Directory-integrated zones provide enhanced security for DNS updates and zone replication traffic in several ways: all DNS servers hosting Active Directory-integrated zones must be registered in AD, AD replication traffic is encrypted, and you can use access control lists (ACLs) to restrict the hosts that are allowed to update RRs using DDNS (secure dynamic updates).

  • Stealth servers When you register the name servers that are authoritative for your Internet domain namespace, you must supply at least one or two name servers that are authoritative for the zone so that authority can be delegated from the parent domain (.com, .net, and so on) to your servers. It is possible, however, for these servers to be secondary, or slave servers to a primary master server that is not listed in the registered NS records for the zone listed by the registrar as being authoritative for your domain. Usually, the primary master server is located behind a firewall, and access to the primary server itself and zone transfers to the secondary servers are tightly controlled by access rules on the firewall.

  • Caching name servers A caching name server performs queries on behalf of DNS, but the server itself is not authoritative for any zones. When you first set up a Windows DNS server with the root hints file, it is a caching name server that can resolve queries for Internet hosts using information it possesses about the name servers that are authoritative for the root zone. After time, the caching name server builds up a list of commonly queried names in its cache, which is subsequently used to answer queries on behalf of clients.

  • Forwarding servers A forwarding server is a kind of caching name server that sends queries to a predetermined list of name servers, known as forwarders, which can perform recursive queries on its behalf. The forwarding server will send its query to each forwarder in its list until it receives a positive or negative response. After it exhausts the name servers in its list, it can be configured to send requests to servers on the Internet using its root hints file. Alternatively, a forwarder can be configured to stop at this point, by disabling recursion, and send a negative response back to the original DNS requester if the forwarder cannot resolve the query. If recursion is disabled on the forwarding server, it is referred to as a forward-only server. There are a number of uses for forwarding servers and forwarders. They are often used when you want to tightly control which DNS servers (the forwarders) are able to send and receive DNS traffic through your firewall. Another common use of forwarders is to handle DNS queries performed across relatively slow WAN links on a corporate network. In the remote network, a name server is configured to forward queries to a more powerful caching name server that has a larger cache and is better able to resolve DNS queries as result of having access to more bandwidth, rather than send its queries directly to the Internet. A new feature of Windows Server 2003 DNS allows the configuration of conditional forwarding. Conditional forwarding allows the DNS administrator to configure the forwarding server to contact specific name servers based on the domain name specified in the query. To configure a conditional forwarder, you specify the domain name and the IP addresses of the servers that are responsible for resolving host names in these domains. Conditional forwarders provide intelligent name resolution and are typically used to reduce the amount of traffic related to recursion on your network.

  • Nonrecursive servers A nonrecursive server is one on which you have disabled recursion so that it is not able to perform recursive queries on behalf of DNS requesters. Disabling recursion on a name server also prevents it from using forwarders to resolve queries. Usually, recursion is disabled on authoritative name servers that provide name resolution for DNS requesters on the Internet, performing queries to locate your Internet hosts such as your Web and mail servers. By disabling recursion on these name servers, you ensure that the servers will respond positively only to queries for RRs in zones for which they are authoritative, and hence tighten the security of these servers. DNS clients on the Internet will not be able to configure their TCP/IP settings to point to your DNS servers for name resolution.

These name server roles are only logically separate from one another. It is possible to combine roles on a single name server. For example, a DNS server can be configured to be a primary master for one domain zone file and as a secondary for other domain zone files. However, it is often advantageous to separate these roles and place them on separate servers. By doing so, you are better able to design your DNS infrastructure to take into account the contingencies of your network infrastructure, such as the speed of your WAN links, the presence of firewalls, the need for security, and so on.

Domain Controller versus Member Server

In an AD environment, you have the choice to install and configure DNS on your domain controllers or on member servers. If you install DNS on your domain controllers, you can configure Active Directory-integrated zones.

Active Directory-integrated zones provide the following advantages over standard DNS zones:

  • There is not a single point of failure for the primary zone. In a standard DNS environment, if the primary master DNS server fails and is not brought online within a particular amount of time (specified in the SOA record), the secondary servers will remove the RRs from their zone, and name resolution will fail for the entire domain.

  • In large environments where DHCP servers and clients are updating RRs, this load can be distributed among domain controllers that store zone information in AD.

  • Active Directory-integrated zones provide enhanced security for zone replication in that DNS servers must be registered in AD and AD replication traffic is encrypted.

  • You can use secure dynamic updates with Active Directory-integrated zones to tighten security further.

  • Synchronization of zone information occurs automatically through AD replication. No further configuration is necessary to facilitate transfer of zone information among participating servers.

  • AD replication is more efficient than the standard zone transfer mechanisms. For example, AD replication propagates only the last changes. Even though an incremental zone transfer copies only the changes to the RRs, it propagates all the incremental changes to the RRs that have occurred since the last update. If you are not using IXFR, the entire zone file is copied whenever an update is made.

  • AD replication will compress replication traffic in certain circumstances, further reducing the bandwidth needed for DNS-related traffic.

start sidebar
New & Noteworthy...
Using the Application Directory Partition for Active Directory-Integrated Zones

Windows Server 2003 enhances the design and functionality of AD through the application directory partition, which is a new feature of Windows Server 2003. In Windows 2000, Active Directory-integrated zones are contained in the domain partition and are replicated to all domain controllers, regardless of whether the DNS service is installed on those computers. In contrast, Windows Server 2003 installs an application directory partition on only those domain controllers that have the DNS service installed. The application directory partition allows you confine DNS-related replication to a subset of computers that have the partition installed. By using application directory partitions, you can reduce the size of the Global Catalog and the amount of replication traffic between domain controllers. This is a significant advantage when you have a large infrastructure in which DNS or another application is making a large number of frequent updates to AD, which would otherwise flood your network with replication traffic and negatively affect domain controller performance.

When you are installing the first Windows Server 2003 AD domain controller, two application directory partitions are created by default: ForestDNSZones, a forest-wide partition, and DomainDNSZones, a domain-wide partition for each domain in the forest.

end sidebar

Active Directory-integrated zones can be used in combination with secondary servers. For example, you can use secondary zones on servers that are not configured as domain controllers. This is advantageous in situations where you do not want AD traffic replicated across a WAN link, but you do want to have an authoritative DNS server available at a remote location. You cannot simultaneously load a standard text-based primary zone file and an Active Directory-integrated zone for the same domain on the same domain controller. However, you can combine primary, secondary, and Active Directory-integrated zones on the same domain controller. On a stand-alone or member server, primary and secondary zones can be combined on the same server. Furthermore, if you have multiple IP addresses bound to the server, you can emulate a secondary server on the same computer where the primary is located. This configuration is useful in very small environments where you have only one server.

Planning for Zone Replication

EXAM 70-293 OBJECTIVE 2.7.2

In planning your DNS infrastructure, you need to decide on the number and placement of your DNS servers. In particular, you must decide which servers will host zone files for your domains. Distributing zone files across your network has a number of advantages. For example, distributed zone files reduce the network traffic caused by DNS queries, increase availability and fault tolerance, provide load balancing, and result in shorter query response times. However, distributing zone files requires that you replicate zone information among your DNS servers, increasing traffic associated with zone transfers or AD replication (if you have enabled Active Directory-integrated zones). Zone files also increase the storage space requirements on DNS servers. Furthermore, replicating zone information increases the administrative effort required to maintain the DNS infrastructure.

In planning for zone replication, you must decide which mechanism you will use for zone replication: either standard DNS zone transfers or AD replication. This decision will depend on a number of factors including the storage location (file-based or AD), the type of zone information (primary, secondary, or stub), and whether you need enhanced security.

If you are using stand-alone, member servers, or other implementations of DNS such as BIND, you must use standard DNS mechanisms for zone transfers. Depending on the version of DNS or BIND you are using, you can use either full (AXFR) or incremental (IXFR) zone transfers to propagate zone information. Incremental zone transfers reduce traffic by propagating only the incremental changes since the last update.

Note

You cannot use IXFR on Windows NT 4 DNS servers or on versions of BIND earlier than BIND 8.2.1.

Microsoft and other DNS servers optimize traffic associated with standard zone transfers by compressing the zone transfer information and including multiple RRs in individual TCP packets. This mechanism is referred to as fast zone transfers (it should not be confused with IXFR). Versions of BIND earlier than 4.9.4 do not support fast zone transfers. Support for fast zone transfers to BIND secondaries is enabled by default on Microsoft DNS servers, but it can be disabled.

A zone transfer is initiated when the secondary servers determine that the version number in their SOA RR is lower than the version number in the primary’s SOA RR, indicating an update to the primary zone. The secondary servers will compare the SOA version number in the following situations:

  • When they are notified of a change by the primary server

  • When the refresh interval specified in the SOA has elapsed

  • When the DNS service on the secondary server is started

  • When a zone transfer is manually initiated by the administrator

When the secondary server determines it needs to update its zone file, it will make a request for an incremental zone transfer (IXFR) or a full zone transfer (AXFR).

The notify list should contain only the IP addresses of secondary servers. It is not necessary to use this list to notify other domain controllers that have a copy of the Active Directory-integrated zone. Active Directory-integrated zones poll approximately every 15 minutes for updates. In fact, adding domain controllers to the notify list can actually degrade performance. Figure 6.7 shows the property pages for configuring a secondary zone transfer notify list.

click to expand
Figure 6.7: Configuring a Notify List for Zone Transfers

Note

You should carefully consider the implications of the configuration settings for zone transfers. Configuring IP addresses in the notify list will increase the frequency and amount of zone transfer traffic on your network. If it is important that secondary servers be as up-to-date as possible, you should include their IP addresses in the notify list. Increasing the refresh interval in the SOA RR will decrease the frequency of polling by secondary DNS servers and consequently decrease the frequency of zone transfers. If decreasing the amount of zone transfer traffic is a more important consideration than currency up to date DNS data on the secondary DNS servers, you should leave them off the notify list and increase the refresh interval. It might be desirable to do this, for example, if the secondary DNS is separated from the primary DNS by a slow WAN link.

Active Directory-integrated Zone Replication Scope

If you are using AD, you can use Active Directory-integrated zones that rely on AD to propagate zone information among domain controllers. Active Directory-integrated zones can further assist in reducing replication traffic because they replicate only the last change to RRs, rather than the incremental changes, and can compress replication traffic. Furthermore, if all your domain controllers are running Windows Server 2003, you can further reduce this replication traffic by defining a scope for the replication of DNS-related information in AD. This is accomplished by leveraging a new feature of Windows Server 2003, the application directory partition (discussed previously). The broader the scope of replication, the more replication traffic that is generated.

In a Windows Server 2003 environment, you must specify an Active Directory-integrated scope. The choices for the replication scope are described in Table 6.1.

Table 6.1: Active Directory-integrated Zone Replication Scope Options

DNS Zone Replication Scope

Description and Usage

All DNS servers in the AD forest

This is the broadest scope for DNS zone replication and produces the most replication traffic. Zone data is replicated to all Windows Server 2003 domain controllers on which the DNS service is installed in the entire forest. You can use this option only when all your domain controllers are running Windows Server 2003.

All DNS servers in a specified

AD domain

This is the default zone replication setting for DNS installed on Windows Server 2003 domain controllers. Zone information is replicated to all the Windows Server 2003 domain controllers on which the DNS service is installed in the domain. This option is desirable when you want to limit or restrict replication of zone information to only the domain controllers in your AD domain. Zone information is not replicated to Windows 2000 domain controllers.

All domain controllers in the AD domain

This option replicates DNS zone information to all domain controllers in the AD domain, regardless of whether or not the DNS service is installed on them. This option is desirable in mixed environment where Windows 2000 domain controllers are used.

All domain controllers specified in the replication scope of a DNS application directory partition

This option allows the customization of your zone replication environment. To use this option, your Windows Server 2003 domain controllers running DNS must be enlisted in the application directory partition. You can use the Dnscmd command-line utility to enlist DNS servers. The syntax for the command is dnscmd [DNS_server_name] /EnlistDirectoryPartition [FQDN of partition]. All fields are required.

A significant advantage of using the application directory partition to store zone data is that the data is not replicated throughout the AD forest in the Global Catalog. This would be the case if AD zone data were stored in the domain partition, as it is in Windows 2000. When using intersite replication (replication between different sites), the application directory partition is replicated according to the same schedule as the domain partition.

To change the replication scope, you can use the DNS console, which presents the choices indicated in Figure 6.8. There are four choices, corresponding to the descriptions in Table 6.1. The choices are to replicate zone data to all DNS server in the AD forest, to all DNS servers in the AD domain, to all domain controllers in the AD domain, and to all domain controllers specified in the scope of [a specified] application directory partition. The last choice to customize the zone replication environment is grayed out and unavailable because the server has not been enlisted in other partitions.

click to expand
Figure 6.8: Changing Replication Scope for Windows Server 2003 Active Directory-integrated Zones

By default, when you first create an Active Directory-integrated zone and an application directory partition has not been created, you have the option of creating the partition using the DNS console utility. You can also use the Ntds utility to create or delete application directory partitions and the Dnscmd utility to create the default application directory partitions. If the default partitions have already been created, you will get an error message indicating that the partition already exists. When you use the DNS console utility to create the application directory partition, you are presented with two exclusive choices:

  • To create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the domain. If you respond No to this choice, you will be presented with the second choice.

  • To create a single application directory partition that stores DNS zone data and replicates that data to all DNS servers in the forest. This creates the broadest scope for replication of DNS zone data.

Figure 6.9 shows the choices for creating an application directory partition using the DNS console. The two dialog boxes below the DNS console window appear when you use the DNS console to create the default application directory partitions.

click to expand
Figure 6.9: Creating the application directory partition using the DNS console

Note

In order for the application directory partition to exist, the domain naming master Flexible Single Master of Operations (FSMO) role must be running on a Windows Server 2003 domain controller. In situations where you have upgraded a Windows 2000 domain controller to Windows Server 2003 and wish to change the replication scope from the domain to the application directory partition, you must first ensure that a Windows Server 2003 domain controller is the domain naming master. Otherwise, you will get an error message when you try to change the replication scope.

Security for Zone Replication

It is also important to ensure that zone replication traffic is secure, especially in situations where standard zone transfers are occurring over the Internet. To secure zone replication, you can configure Microsoft DNS to transfer zone information to only those servers that are found in the zone’s name server list. However, you can further tighten security by specifying individual IP addresses that are allowed to receive zone transfers.

In situations where you are transferring zone transfer information over the Internet or you are concerned that this traffic can be intercepted, you should also consider using Virtual Private Network (VPN) tunnels or Internet Protocol Security (IPSec) to encrypt this traffic. Recent versions of BIND can use transactions signatures (TSIG) to secure zone transfers, but Microsoft does not support secure zone transfers to secondary zones. Hence the need for VPN tunnels and IPSec.

Using Active Directory-integrated zones also increases the security of your replication data by ensuring that all DNS servers are registered in AD and by using the security mechanisms inherent in AD replication. The security for zone transfers arises from the security of AD when you use Active Directory-integrated zones. Where possible, you should use Active Directory-integrated zones exclusively to improve performance and security of zone replication traffic.

General Guidelines for Planning for Zone Replication

You should keep the following guidelines in mind when planning for the distribution of zone files in your infrastructure:

  • Limiting the number of zones of authority in your DNS infrastructure simplifies administration. For each subdomain that has a separate zone of authority, you must ensure that the delegation of authority is correct for the subdomain and plan for the appropriate zone replication for each of these subdomains.

  • Distributing zone files increases the traffic associated with zone transfers or AD replication.

  • Distributing zone files reduces the amount of traffic associated with name resolution queries.

  • Distributing zone files provides a means for supporting a disjointed namespace.

  • Distributing zone files increases availability and fault tolerance. It also reduces query response times.

  • If you are using Active Directory-integrated zones and all your DNS servers are installed on Windows Server 2003 domain controllers, you can use an application directory partition to reduce the replication traffic associated with the transfer of zone information.

  • You can minimize the bandwidth consumed by standard zone transfers by modifying the schedule for transfers to secondary zones.

  • You should configure a primary server to notify only secondary servers. However, you should note that configuring the notify list to transfer zone information with the IP addresses of servers hosting the Active Directory-integrated zone can actually degrade performance.

  • If you are using standard DNS zone transfers, you should try to implement incremental zone transfers and fast zone transfers where possible.

  • A DNS server that is hosting an Active Directory-integrated zone or a standard primary zone can also host a standard secondary zone for another domain.

  • A stub zone is a synchronized copy of a subset of an authoritative zone’s RRs: the SOA, NS, and glue address records that identify authoritative name servers for a particular domain.

  • A stub zone can reduce cross-domain referral and other DNS traffic.

  • Security of zone data should be a consideration in your design and implementation. Active Directory-integrated zones provide more security than standard zone types. If you are using standard zone types, security can be enhanced by restricting the hosts that are allowed to receive zone transfers and by encrypting zone transfer traffic using VPN tunnels or IPSec using the strongest level of encryption possible.

Planning for Forwarding

EXAM 70-293 OBJECTIVE 2.7.3

Distributing zone files throughout your infrastructure provides one means of ensuring efficient DNS name resolution. However, it is not always desirable or possible to distribute zone files to facilitate efficient DNS name resolution.

Consider a situation in which a large company has a small branch office connected by a slow WAN link. If the branch office were to host a copy of the zone files, the zone replication traffic could overwhelm the slow WAN link. In a situation like this, it is advantageous to configure a DNS server in the branch office that forwards DNS queries to specific servers in the main office. This increases the amount of name resolution traffic that crosses the WAN link, but it eliminates the more significant zone replication traffic.

It might also be advantageous in this situation to configure the DNS server in the branch office to forward all queries for Internet name resolution to a forwarder in the main office that is better able to resolve Internet queries. This forwarder can resolve queries directly by contacting authoritative DNS servers on the Internet using its more ample bandwidth and capacity, or it may be able to resolve queries from its larger cache.

A forwarder is simply a DNS server that receives queries that are forwarded to it by other DNS servers that are not capable of resolving the DNS query. Whenever a DNS server receives a query, it will try to answer the query from the data stored in its zone files or cache. Unless it has been configured otherwise (that is, as a nonrecursive server or a root-level server), if the DNS server cannot answer the query from its data it will either contact authoritative root servers or forward the query to a forwarder.

A forwarding server configured to use recursion if the configured sets of forwarders are unable to resolve name queries. This configuration might be desirable in situations where you want the DNS server to continue to attempt to resolve queries in the event that the forwarders are unable to do so. If the forwarders are unable to answer queries, the forwarding server will continue to use standard DNS methods to resolve the queries starting with the root-level servers. However, this configuration might not always be desirable or possible. In this case, you can configure the forwarding server to not use recursion if the queries to the forwarders fail. If resolution fails using the configured set of forwarders, the name resolution process stops and a negative response is sent to the DNS client.

Servers that are configured to not use recursion are called forward-only servers. You configure a forward-only server by checking the box labeled Do not use recursion for this domain in the Forwarders property page (see Figure 6.11 in the next section).

Using forwarders can help reduce the amount of DNS traffic related to recursion in addition to reducing the traffic related to zone replication. Their use can also help to enhance security by minimizing the number of DNS servers that need to communicate with one another across firewalls. Other advantages can be realized by using conditional forwarding, a new feature of Windows Server 2003 DNS.

Conditional Forwarding

Conditional forwarding adds intelligence to the forwarding of DNS queries. In previous versions of Microsoft DNS, you could configure a forwarding server to forward queries for all domains it could not resolve to only a single set of forwarders. In this setup, the list of forwarders was responsible for resolving names for the entire domain namespace on behalf of the forwarding server. With conditional forwarding, it is possible for the DNS administrator to configure a forwarding server to contact different sets of forwarders based on the domain name in the query. Figure 6.10 shows a possible design configuration for conditional forwarding.

click to expand
Figure 6.10: Conditional Forwarding Configured to Send Queries Directly to an Authoritative Server

In Figure 6.10, dns1.shinder.net has been configured to send any query requests for hosts in the corp.tacteam.net domain directly to dns1.corp.tacteam.net, which is authoritative for the zone. If conditional forwarding had not been configured, dns1.shinder.net would need to send a set of iterative queries to the root servers and dns1.tacteam.net in order to find the server that is authoritative for corp.tacteam.net. This configuration helps to eliminate network traffic related to DNS name resolution and reduces DNS query response time. Also, since dns1.shinder.net is a direct point of contact with dns1.corp.tacteam.net, over time it would acquire a significant number of cached RRs for hosts in the corp.tacteam.net domain.

You can also imagine in this configuration that corp.tacteam.net is the forest root domain for AD. In this situation, it is both possible and highly desirable to limit DNS access through the firewall that protects the internal network for corp.tacteam.net to specific forwarding DNS servers.

As you can also infer from this scenario, using conditional forwarders eliminates the need to use secondary zones to support a disjointed namespace. It is not necessary to host a secondary zone for the corp.tacteam.net zone on the shinder.net network. (You could also use stub zones to eliminate the need for the secondary zones, but conditional forwarding is a preferable solution.) To increase the fault tolerance of this solution, you should specify more than one forwarder in the list of servers for the forwarding server to contact to perform name resolution for the remote domain.

Figure 6.11 shows conditional forwarding configured for the corp.tacteam.net domain. Note that you can disable recursion on a per-domain basis.

click to expand
Figure 6.11: Conditional Forwarding for the corp.tacteam.net Domain

General Guidelines for Using Forwarders

The following guidelines might assist you in planning to use forwarders as part of a DNS infrastructure:

  • Forwarders can eliminate the need to host secondary zone files across slow WAN links that might otherwise saturate bandwidth during zone replication.

  • Conditional forwarders can directly query authoritative name servers based on the domain name in the query.

  • Conditional forwarders can assist in providing support for a disjointed namespace and are a preferred solution over using stub zones for the same purpose.

  • Fault tolerance can be enhanced by specifying multiple forwarders and by enabling recursion if queries to forwarders fail.

  • Using forwarders can enhance security by minimizing the number of DNS servers that need to communicate with each other across firewalls.

    Exam Warning

    Conditional forwarding is an important new and useful feature of Windows Server 2003 DNS. You should be familiar with configuring conditional forwarding and understand the reasons that conditional forwarding is a preferable solution in a given environment.

DNS/DHCP Interaction

As is the case with Windows 2000, Windows Server 2003 supports the DDNS standard (RFC 2136) to dynamically update both forward and reverse lookup zones with A and PTR RRs, respectively. (A forward lookup zone resolves host names to IP addresses; a reverse lookup zone resolves IP addresses to host names.) DDNS reduces much of the administrative burden in managing a zone files in a DNS infrastructure. In particular, DDNS makes it possible for AD domain controllers to create and update the SRV RRs that are fundamental to the proper operation of AD. DDNS is also used in combination with DHCP to ensure that DHCP clients will have the appropriate records registered for them in DNS and the DNS records are updated whenever IP addresses change or DHCP leases expire.

Both clients and DHCP servers are capable of updating the zone records. However, only clients that are running Windows 2000, Windows XP, or Windows Server 2003 operating systems are capable of directly updating DNS zones. This is the default configuration for these clients and can be disabled on the DNS tab of the Advanced property page for TCP/IP. Usually, DHCP clients will update their own A records in the forward lookup zone, but the DHCP servers will update the PTR record in the reverse lookup zone (the computer “owns” the host name, but the DHCP server “owns” the IP address). Clients with manually configured IP addresses will always try to register both an A and a PTR record. Other level clients, such as Windows 9x and Windows NT 4, must rely on DHCP servers to update both A and PTR RRs on their behalf.

When a client or a DHCP server attempts to update an RR, it will first query the DNS server that it is configured with to find the DNS server that is authoritative for the domain name it is trying to register. Once it determines this information, the DNS client will send an update request to the server that is authoritative for the zone. If the update request meets the prerequisites for updating the record, the record is updated. If the prerequisites are not met, the update fails. The client is notified of either the success or failure of the update. In the case of failure, the DNS client will attempt to register the record again in a 5-, 10-, and then a repeated 50-minute interval.

DHCP clients that are capable of dynamically updating DNS records use the DHCP client option 81 to provide the FQDN as specified by the full computer name in the properties of the My Computer object, and instructions for the DHCP server to handle DDNS registration. (This is configured on the DNS tab of the Advanced property page for TCP/IP of the client computer.) The client’s FQDN is used to register the name with the appropriate DNS server that is authoritative for the zone. Other level clients will be registered with DNS servers that are authoritative for the domain name configured for the DHCP scope.

start sidebar
Head of the Class...
DHCP Client and Netlogon Service

The ability for a Windows XP and Windows 2000 Professional client to update a DNS record requires the DHCP client service to be running. The DHCP client service, rather than the DNS client service, is responsible for sending dynamic update requests to the primary DNS. The reason for this is to ensure that updates to the zone file occur whenever there is a change in the IP address associated with a computer as a result of DHCP. This is true regardless of whether or not the client is configured to acquire its TCP/IP configuration from a DHCP service or has a static TCP/IP configuration. When a client creates a DNS registration, it will use a default value of 20 minutes for the TTL on record, which overrides the min TTL value in the SOA record. Using the DHCP client service, DNS clients will send an update request opcode every 24 hours for their A and PTR records. If there is no change to the name and IP address mapping, this update request is considered a refresh and does not result in a change to the version number of the DNS zone file.

The situation for servers and domain controllers is a little different, owing to the importance of having accurate DNS data for these computers. These computers send an update request every hour. If the computer is a domain controller, the Netlogon server is responsible for sending the update every hour. A, PTR, CNAME. and SRV records. (In the case of Windows 2003 domain controllers the update interval is every 15 minutes.)

For more information about this topic, see the Microsoft Knowledge Base article “How to Enable/Disable Windows 2000 Dynamic DNS Registrations” at http://support.microsoft.com/default.aspx?scid=kb;en-us;246804.

end sidebar

A DHCP server will do the following, depending on its configuration:

  • Update the A and PTR records, if requested by the client.

  • Always update the A and PTR records, regardless of the client request.

A DHCP server will attempt to update A and PTR records if requested by the client. Figure 6.12 shows the default configuration for the DHCP server on the properties page for the DHCP server in the DHCP console. A similar property page exists for the DHCP scope.

click to expand
Figure 6.12: Default DHCP Configuration for Dynamic DNS Updates

To configure the DHCP server to update DNS records, regardless of the client request, you can select the radio button labeled Always dynamically update DNS A and PTR records. If you wish to configure DHCP to perform DNS updates on behalf of legacy clients, you can select the check box labeled Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0). By default, the DHCP server is configured to remove both the A and the PTR records from the DNS zone. You can change this behavior by clearing the box labeled Discard A and PTR records when lease is deleted. When you clear this box, the DHCP will attempt to remove the PTR record when the lease expires.

Security Considerations for DDNS and DHCP

Implementing DDNS creates some security risks in that unauthorized computers and users might be able to update DNS records. In the case of public Web servers, the consequences of the unauthorized registration of a rogue Web server IP address to replace a valid one can be very significant indeed. For this reason, it is not a good idea to enable DDNS on any zones that are used to resolve names for your Internet-facing servers.

To mitigate the risk of unauthorized updates, you can require the use of secure dynamic updates. However, the option to use secure dynamic updates is available only if you are using Active Directory-integrated zones. (On a standard primary zone, you have two choices for security: secure and non-secure.) When you enable this option, you are able to control which computers, users, or groups are able to modify RRs in the zone. For this reason alone, you should consider the using DDNS only if you are using Active Directory-integrated zones.

If you have enabled secure updates, there is a potential for problems caused by the ownership of records. When a DNS client or a DHCP server updates a zone file with an RR, it becomes the owner of that record. Normally, this does not create a problem.

However, in some circumstances, the ownership of an RR can prevent a valid update to it. Consider the case of a client that is upgraded to Windows XP. After the upgrade, it attempts to update the RR in the zone. The attempt will fail because the record is owned by the DHCP server that originally created the record on the client’s behalf. Or, consider the case where a different DHCP server other than the original one, tries to register an update on the client’s behalf. Again, the attempt will fail. To resolve this problem, you can use a special security group called DnsUpdateProxy.

DnsUpdateProxy Group

Any objects that are created by members of the DnsUpdateProxy group have no security and are ownerless. Consequently, the first authenticated computer that updates the record is able to take ownership of the object. Therefore, if you enable secure dynamic updates only, you should place all DHCP servers in this group before they start registering names.

The DnsUpdateProxy group can create a security risk, however, if the DHCP server is installed on a domain controller. If the DHCP server that is a member of the DnsUpdateProxy group is installed on a domain controller, all the SRV, the A records for domain controller on which DHCP is installed and other critical records created by the domain controller for AD functionality will be ownerless, allowing the first authenticated user who tries to update them to become the owner. For this reason, you should not install a DHCP server on a domain controller if you are using the DnsUpdateProxy group.

If, for whatever reason you do need to install DHCP on a domain controller, or if DHCP is updating A records for clients in forward lookup zones, you should configure your DHCP server(s) to use DNS dynamic update credentials. To do this, you configure a security principal (a user account in this case) for use by all your DHCP servers when they update a DNS zone. You then configure your DHCP servers to use this account for dynamic updates. (This is a new feature of Windows Server 2003 and is not available on Windows 2000.) This obviates the problems arising from ownerless records created by DHCP servers in the DnsUpdateProxy group. In particular, enabling this configuration prevents a DHCP server from using the elevated permissions it inherits by virtue of its being installed on a domain controller. Figure 6.13 shows the Advanced tab on the DHCP server property page where you configure credentials for dynamic updates.

click to expand
Figure 6.13: Configuring Credentials for DHCP Updates to Dynamic Zones

start sidebar
Head of the Class...
Generic Security Service TSIG (GSS-TSIG) and Dynamic Updates

Microsoft uses a dialect of transaction signatures (TSIG) as the underlying mechanism for secure dynamic updates, as specified in RFC 2485. This dialect, Generic Security Service TSIG (GSS-TSIG), is not spoken by other implementations of DNS. A version of BIND 9.x is supposed to provide this support in the future, but as of this writing, BIND 9.2 (the most current version) does not provide this support. This lack of interoperability can cause issues if you are trying to integrate BIND into your Windows environment. For example if you want a BIND server to handle all your dynamic updates, which makes the zone become a much more complex administrative challenge, as well as if you want a BIND DNS client to be able to update records using secure dynamic update.

In BIND 9, TSIG is used primarily for secure server-to-server communications (for example, zone transfer, notify, and recursive query messages). However, TSIG can be used in a BIND environment for secure dynamic updates.

end sidebar

Aging and Scavenging of DNS Records

When you enable zones for dynamic updates, it is possible that the zone data files will acquire a large number of superfluous and outdated records that might have a negative effect on DNS performance. For example, if you retire a user’s workstation and disconnect it from the network, the RRs for that computer might remain in the DNS data. To help ensure the integrity and currency of DNS data, you can enable aging and scavenging of outdated DNS records. (By default, the aging and scavenging option is not enabled.)

Aging and scavenging can be set on a per-zone or per-DNS server basis. Per-zone settings override per-DNS server settings. Figure 6.14 shows the server-wide aging and scavenging property page.

click to expand
Figure 6.14: Aging and Scavenging Settings for a DNS Server

The No-refresh interval setting is the amount of time that must elapse before a DNS client or DHCP server can refresh a timestamp for a record. When a DNS client creates a record, it is assigned a timestamp. The DNS client attempts to refresh this record every 24 hours. Unless the record is changed (for example, the client receives a new IP address), the timestamp cannot be refreshed for a default period of seven days. After the seven days have elapsed, the DNS client can refresh the timestamp, which starts the timer on the no-refresh interval for the record. If the record is not refreshed in the seven-day period, it can be scavenged. When the record is scavenged, however, depends on another setting, the Scavenging period. This setting is enabled and configured on the Advanced tab of the property pages for the DNS server. To enable scavenging, you must enable this setting, as well as the settings for No-refresh interval and Refresh interval.

Exam Warning

DDNS and its interaction with DHCP are important concepts. You should be thoroughly familiar with the implementation of DDNS and DHCP to support dynamic updates to DNS zones. Your understanding of these concepts should also be informed by a thorough understanding of the security implications for enabling DDNS.

Windows Server 2003 DNS Interoperability

EXAM 70-293 OBJECTIVE 2.7.5

In addition to it interoperability with DHCP, the Windows Server 2003 DNS is designed to interoperate with other implementations of DNS such as BIND, and with other Windows Server 2003 services such as WINS. In this section, we examine the interoperability of Windows Server 2003 with other DNS servers and Windows Server 2003 services.

BIND and Other DNS Server Implementations

One of the design goals of Windows 2000 and Windows Server 2003 is to ensure that they conform as much as possible with TCP/IP and other standards, as defined by various organizations and governing bodies. This, in turn, helps to ensure that Windows can interoperate with a wide variety of heterogeneous systems.

With some exceptions, such as the addition of functionality required for the interoperability of DNS and WINS, Windows Server 2003 DNS is a completely standards-based implementation of DNS. As such, it will interoperate with other standards-based implementations of DNS, such as BIND. In fact, in many cases, it is not necessary to forsake a current implementation of DNS for Windows Server 2003 DNS as long as the implementation of DNS supports current DNS standards. That said, management of your DNS infrastructure is easier if all your DNS servers are Windows Server 2003 servers.

The degree of interoperability will depend on the version of BIND with which the Windows Server 2003 DNS server interacts. Like other standards, the standards for DNS are evolving, and earlier implementations of DNS such as the DNS in Windows NT 4 or earlier versions of BIND will not interoperate completely with Windows Server 2003 DNS. In some cases, the presence of downlevel and legacy implementations of DNS can create problems in the DNS infrastructure.

BIND stands for Berkeley Internet Name Domain and was developed by a group of graduate students at University of California at Berkeley in the mid-1980s for use on UNIX operating systems. BIND is now the responsibility of the Internet Software Consortium (ISC). The ISC’s first release was BIND 4.9.3. BIND 8 was released in 1997. BIND 9.2 is the most current version as of this writing. BIND 8 is still widely used. The latest version is 8.4.1, and it should be implemented because it fixes a number of security holes and bugs with earlier versions. Version 4 of BIND has been officially deprecated by ISC, and its use is not recommended. However, if BIND 4 cannot be upgraded to BIND 8 or 9, you should upgrade to BIND 4.9.11.

Table 6.2 shows a comparison of features support by various implementations of DNS.

Table 6.2: Windows DNS and BIND Compatibility Comparison

click to expand

Zone Transfers with BIND

BIND supports standard primary and secondary DNS zones. Thus, BIND servers can be used as both primary DNS servers that transfer zone files to Microsoft DNS secondary servers and vice versa. A BIND server can also be configured as a secondary server to an Active Directory-integrated zone. However, an Active Directory-integrated cannot be a secondary zone, so it is not possible for a BIND server to host a primary zone that transfers zone information to a secondary zone configured in AD. Also note that if you want to secure zone transfers between BIND and Microsoft DNS servers, you will not be able to use the TSIG mechanisms available to recent implementations of BIND.

Note

To secure transfers of DNS zones, you must either implement zones that are exclusively Active Directory-integrated or use some other mechanism, such as VPN tunnels and IPSec if you are using standard DNS zones.

Versions of BIND earlier than BIND 4.9.4 do not support the fast transfer method for zone replication. When the fast transfer method for zone replication is enabled, multiple zone RRs are compressed in the TCP/IP packet. Fast zone transfers are enabled by default in Windows DNS. You should disable fast zone transfers only if your secondary DNS servers are running versions of BIND earlier than version 4.9.4. The configuration for fast zone transfers can be enabled or disabled only on a server-wide basis. You cannot enable or disable it on a per-zone basis. Disabling fast zone transfers does not affect zone replication between Windows DNS servers. Figure 6.15 shows the default configuration that enables fast zone transfers. To disable fast zone transfers for BIND secondary servers, navigate to the Advanced tab of the property pages for the DNS server and clear the check box for BIND secondaries.

click to expand
Figure 6.15: Enabling Fast Zone Transfers for BIND Secondaries

Windows DNS zone files can contain RRs that can cause problems for BIND secondaries. These records include those that use an underscore in the host or domain name and the WINS and WINS-R records. On some versions of BIND, notably BIND 8.0, the presence of these records can cause the zone to fail to load.

Although the underscore is a valid character in a NetBIOS name, it is not a valid character for DNS host names, according to RFCs 851, 952, and 1123. (The underscore is a valid character for domain names, and the more recent RFC 2181 specifies that any binary string can be used to represent a host name, but not all DNS servers conform to the standards specified in RFC 2181.) BIND version 8, in particular, will have problems if it encounters underscores in the host or domain names when it loads the data for the secondary zone. This is a result of a feature in BIND 8 known as name checking, which restricts the character set used for host and domain names. If underscores are present in host names, you have two choices: rename the computers so that their names do not have underscores, or disable name checking on the BIND 8 server by changing the default check-name setting on the BIND 8 server from Fail to Warn or Ignore.

If a BIND 8 server is hosting a primary or secondary zone for AD SRV records, the only choice is to disable name checking, because these records contain underscores in the domain names, and these cannot be changed. (BIND 9 does not restrict the character set for domain names, so this is not an issue if you are running BIND 9.)

The proprietary WINS forward and reverse lookup records also create problems for BIND secondaries. In this case, the issue is caused by the deed WINS record is not part of the DNS standard and not recognized by other DNS servers. Non-Microsoft DNS servers will see the WINS forward and reverse lookup records as bad records, causing either data errors or the failure of the zone to load. If you are using BIND secondaries for a zone hosting WINS records, you have two choices: configure the WINS records not to replicate or configure a separate referral zone for WINS records. It is preferable to configure a separate referral zone for WINS records, because clients who contact secondary DNS servers might get different answers from those clients who contact the primary DNS server. We will discuss WINS and DNS interaction in more detail later in this chapter.

Supporting AD with BIND

As we mentioned earlier, you can support AD using BIND servers rather then Windows Server 2003 DNS. The minimum requirement for a DNS server to support AD is that it be able to host SRV records in its data. DDNS is only an optional requirement for a DNS server. Thus, a Windows NT 4 DNS with Service Pack 4 or later could be used to support AD records.

To host AD records, the minimum version of BIND that must be used is version 8.2.2 patch 7. If you use BIND 8, you must configure the check-name setting to Ignore so that it will load a zone containing underscores in domain names. This setting is not necessary on BIND 9 servers because they do not restrict character sets used for domain names.

Both BIND 9 and BIND 8.2.2 are capable of supporting dynamic updates. To allow domain controllers to dynamically register their DNS data, you can configure the allow-update setting in the named.conf configuration file on the BIND servers. However, it is not possible to configure ACLs on individual RRs (as it is when you are using Active Directory-integrated zones configured for secure updates only).

BIND might be uncomfortable, for security and other reasons, with allowing dynamic updates in the master zone file that hosts the DNS records currently in use. The allow-update setting allows you to specify the IP addresses of the servers that can dynamically update records in the zone. However, IP addresses can be spoofed, so this isn’t a very strong level of security.

Note

Secure dynamic updates can be configured for secure zones hosted on BIND servers by using DNSSEC, as per RFC 3007. However, because many of the standards that govern secure updates and related issues are in the immature stages of being developed as officially accepted standards, Microsoft chose not to implement the same standards as BIND. (There is currently no single IETF standard for secure dynamic updates that addresses interoperability of the various mechanisms for secure updates.) Thus, Windows clients and DNS servers are not able to use DNSSEC mechanisms to provide secure dynamic updates for zones hosted on BIND servers.

One way to mitigate the risk of using BIND servers for dynamic updates is to create subdomains to host the AD DNS data. For example, if the domain name is mycompany.com, you can create a separate zone called ad.mycompany.com. To create this zone, you must issue a zone statement specifying the zone name and the location of the files in the named.conf file on the BIND server. However, Microsoft Active Directory-integrated zones still provide a much higher level of security. For this reason, it is preferable to use Active Directory-integrated zones. BIND administrators can delegate authority to a subdomain hosted in Active Directory-integrated zones and configure BIND servers as secondaries to this zone to enhance fault tolerance and availability.

Split DNS Configuration

Many organizations want to use the same name on their internal network as they do on their publicly available external network. For example, suppose that a company’s name is mycompany.com and its Web server and e-mail servers located in the DMZ use this domain name in their FQDN. The company also wants to use this name for its AD domain on the internal network. This situation creates a number of challenges. Foremost among these is security of internal DNS records. It is not desirable to expose internal host names and IP addresses to external clients, even if these hosts cannot be reached by external clients because of restrictions on the firewall. Also, it is not a recommended DNS best practice to include any record in a zone file for a host that is unreachable.

At a minimum, a properly secured DNS configuration requires that the DNS records for the internal namespace be accessible to internal clients only and not accessible to external clients. Furthermore, internal clients should be able to resolve queries for external hosts on the Internet so that e-mail servers are able to send mail to external hosts and users are able to connect to the Internet. Finally, the bastion hosts (computers that can communicate with both the Internet and the intranet) that are responsible for delivering e-mail to the internal network should be able to successfully locate and communicate with the appropriate internal servers through the firewall.

This situation implies the use of a split DNS configuration. A split DNS configuration requires two sets of name servers for the same namespace. For example, suppose that a set of DNS servers in the DMZ contains records for the hosts, such as the A records for the Web servers, the MX and A records for the mail servers, and the NS and A records for the DNS servers in the DMZ. Another set of authoritative DNS servers that contains records for internal hosts is configured in the internal network for the same namespace. The DNS servers configured on the internal network are not accessible to external clients for name resolution.

Internal clients should also be able to gain access to the company’s publicly available Web servers. Depending on the configuration of the infrastructure, this can create some challenges. For example, if the company is using ISA Server as its firewall and making a Web server in its DMZ available to external clients via Web server publishing rules, internal clients might not be able to connect to the internal Web server if the internal DNS uses an A record for the Web server that points to an external address. Supporting this kind of con

figuration requires that the internal DNS servers use A records that point to the internal IP address of the Web server and not the external IP address that is used to publish the Web server for external clients. In other words, the A records for the Web server will differ in the internal and external DNS servers that are authoritative for the zone. Figure 6.16 shows a possible configuration for a split DNS to allow internal clients to connect to the publicly available Web server.

click to expand
Figure 6.16: Split DNS Configuration to Allow Internal Clients to Connect to the Web Server in the DMZ

Note

Supporting a split DNS configuration involves more effort on the part of the DNS administrator. For example, the DNS administrator might need to manually update separate DNS servers that are authoritative for the same zone. In addition, the DNS administrator must ensure that no records for the internal network appear in the publicly available DNS server.

Interoperability with WINS

In a mixed environment that includes downlevel clients such as Windows NT 4 and Windows 95, you must continue to support NetBIOS name resolution. The primary mechanism for supporting NetBIOS name resolution in a segmented network is through WINS, which allows clients on different subnets to register and resolve NetBIOS computer names on WINS servers. In some situations, it might be necessary for UNIX clients, which do not support NetBIOS, to connect to Windows NT 4 computers. In order to resolve the Windows NT 4 computer names, the UNIX hosts must use DNS. However, if the Windows NT 4 server is configured with a static IP address, it will not be able to dynamically register its host name and IP address in DNS.

One way to support DNS resolution for NetBIOS computer names is to integrate WINS with DNS through WINS forward and reverse lookup records. When a DNS zone is configured with WINS forward or reverse lookup records, it will consult a WINS server to resolve host names for records that are not present in its zone data.

For example, suppose that a UNIX host needs to send a print a job to Windows NT 4 server named PServer1.tacteam.local. The UNIX host sends a query for PServer1.tacteam.local to the DNS server authoritative for the tacteam.local zone. The DNS server does not find a record for PServer1 in its zone data, so it performs a WINS lookup to the IP address of the server listed in its WINS forward lookup record. After receiving a reply from the WINS server, it sends the information to the UNIX host. The DNS server that performs the NetBIOS resolution will keep the record in its cache for a configurable interval (the default is 15 minutes), so that if it receives a query for the same name within the interval, it can resolve the name from its cache.

As a result of this integration with WINS and DNS, it is not necessary for the DNS administrator to manually update the DNS zones with A records for NetBIOS computers that are incapable of updating DNS data on their own. The configuration of WINS forward and reverse lookup records is performed on a per-zone basis. To configure WINS lookup records, go to the forward or reverse lookup zone for which you wish to configure WINS integration, go to the property pages for the zone, and click the WINS tab. Figure 6.17 shows the WINS tab property pages.

click to expand
Figure 6.17: WINS tab for a DNS Forward Zone Showing Advanced Configuration Options

There are a few things to note about the configuration shown in Figure 6.17:

  • Two WINS servers are specified to improve fault tolerance in the event that the first WINS server does not have the record or is unreachable.

  • The check box for Do not replicate this record is selected. The purpose of this configuration is to prevent the replication of WINS records to BIND secondaries that might encounter data errors or fail to load the zone if they encounter the proprietary WINS record in the replicated data.

  • Cache time-out and Lookup time-out values are configured in the Advanced properties of the WINS tab. The Cache time-out value indicates the length of time the DNS server will cache WINS records. The Lookup time-out value indicates the length of time the DNS server will wait for a response from a WINS server.

The WINS forward record has the following format in the zone file:

@          WINS    LOCAL  L2 C900 (192.168.100.20 192.168.179.3)

The @ is a kind of shorthand used in DNS files to indicate the domain name, also known as the origin for the domain, in this case tacteam.local. The LOCAL label indicates that the record should not be sent to secondary servers as part of zone replication. The L2 label refers to the lookup timeout value of two seconds. The C900 label indicates the cache timeout value of 900 seconds, or 15 minutes. Both of these represent the default values. If you have a relatively static environment, it can be advantageous to configure a longer cache timeout value of perhaps an hour or more.

WINS Reverse Lookup Records

Reverse lookup zones are used to resolve IP addresses to host names, rather than host names to IP addresses, as is the case with forward lookup zones. WINS records are not indexed by IP address. Therefore, the WINS server cannot do a reverse lookup. Consequently, in a reverse lookup zone, A WINS-R RR will cause the DNS server to issue a remote adapter node status query using the nbtstat command to determine the NetBIOS name associated with an IP address.

Configuring a WINS-R record in a reverse lookup zone is similar to configuring a WINS record. Figure 6.18 shows the property pages of the WINS-R tab for a reverse lookup zone.

click to expand
Figure 6.18: The WINS-R Tab for a DNS Reverse Lookup Zone Showing Advanced Configuration Options

As with WINS forward lookup records, you have the option of preventing the WINS-R record from replicating to secondary servers. This will prevent problems with BIND secondaries encountering this record in the zone data.

Note that the values in the WINS-R record are different. Instead of specifying the IP address of a WINS server, you specify the domain name that should be appended to the reverse lookup query response. Also, in the Advanced property page, you can check a box to Submit DNS domain as NetBIOS scope. This option should be used only if you are using NetBIOS scopes on a subnet. When this option is selected, DNS uses the host name as a NetBIOS computer name to query the remote adapter node status, but submits the domain name as a NetBIOS scope identifier.

Note

NetBIOS scopes are used in certain, rare circumstances when it is necessary to isolate legacy computers from communicating with other groups of computers on the same subnet.

A WINS-R RR has a similar format to a WINS forward record in the zone data file:

@                       WINSR    LOCAL  L2 C900 (tacteam.local. )

The @ indicates the origin of the domain, in this case the 100.168.192.in-addr.arpa reverse lookup domain. The tacteam.local. value is the domain name that will be appended to the host name.

WINS Referral Zones

In a mixed DNS infrastructure where you are not replicating WINS RRs to secondaries, clients will get varying answers to queries if they query a secondary zone for a WINS record. To get around this problem and to provide a means of organizing and distinguishing between WINS and DNS records, you should configure a WINS referral zone. A WINS referral zone is a delegated child subdomain of the parent domain. The WINS child domain contains only the SOA for the child domain and the WINS RRs. For example, if the parent domain is tacteam.local, you would configure a child domain named something like wins.tacteam.local. If you have a large network with multiple WINS servers for different locations, you could use multiple child domains, such as dallas.tacteam.local and edmonton.tacteam.local. However, in order for this configuration to work in your environment, you need to populate the DNS suffix search list on your DNS clients so that they will append the domain name of the WINS referral zone to unqualified queries (queries that do not use the FQDN). Figure 6.19 shows a possible configuration of a DNS client to support WINS referral zones.

click to expand
Figure 6.19: DNS Client Suffix Search List Configured to Support WINS Referral Zones

You should note that this configuration overrides the default configuration, which is to Append primary and connection specific suffixes and Append parent suffixes of the primary DNS suffix. The default configuration allows a client to send a query for an unqualified host name based on the suffix configured for it in the properties of My Computer and to devolve the domain name to the suffix of the parent domain. For example, if the client FQDN is host1.dev.research.tacteam.local, and it issues a recursive query to resolve the name PServer1 to an IP address, it will first append dev.teacteam.local to the name query. If the query fails, it will subsequently devolve the suffix to the parent domain and append tacteam.local to the name query.

Overriding the default settings for the DNS suffix search list increases administrative effort. However, you can reduce the administration of DNS client settings by using Group Policy settings to supply the clients with a DNS suffix search list. You cannot use DHCP options to specify a custom DNS suffix search list because Option 015 (DNS Domain name), which is used to specify the DNS domain name to append to unqualified queries, allows only one value. If you are implementing a custom DNS suffix search list, you should keep this list as small as possible to reduce DNS traffic on your network.

DNS Security Issues

EXAM 70-293 OBJECTIVE 2.7.4

Security should always be a primary consideration in the deployment of any network service. This is also true of the implementation of a DNS infrastructure. DNS is an open standard that is used throughout the Internet. Over the years, a number of exploits have appeared that can compromise an unsecured DNS infrastructure. When DNS is compromised, hackers can learn information about your internal network that they can subsequently use to launch other attacks. Furthermore, if a DNS server is vulnerable to DoS attacks, hackers can prevent name resolution from occurring for critical servers such as your Web and mail servers. Finally, an unsecured DNS server can be compromised with the addition of false records that redirect traffic to bogus Web and mail servers.

Security measures that you can take to mitigate risk to your DNS infrastructure include those available to standard DNS implementations, such as disabling recursion on Internet-facing servers, as well as those available to Windows Server 2003 DNS only, such as using Active Directory-integrated zones for zone transfers and secure dynamic updates.

As with developing any security policy, it is important to understand the nature and likelihood of the threats involved to determine the cost to the organization if a particular threat is realized, and then compare this cost with that of implementing countermeasures to mitigate the risk to the organization. Certain trade-offs need to be considered. For example, to completely secure your DNS infrastructure from attacks launched from the Internet, the only completely reliable countermeasure is to not have an Internet connection. Obviously, many organizations could not survive without Internet access, so this particular countermeasure is not appropriate.

In the next section, we will take a look at common threats to a DNS infrastructure. Then we will review the standard and Windows-specific countermeasures you can take to mitigate the risk from these threats.

Common DNS Threats

An unsecured DNS infrastructure is vulnerable to a number of common threats. These include footprinting, redirection, and DoS attacks. These threats are described in the following sections.

Footprinting

Footprinting is the process whereby attackers gain information about your internal DNS RRs and are subsequently able to use this information to infer the identity and purpose of servers on your internal network. Attackers can use this information in a variety of ways to compromise the organization. For example, an attacker can use this information to launch data modification attacks using spoofed IP addresses to compromise critical servers and data on the internal network. Another possibility is that, because host names are often informative, the attacker could use this information to infer confidential information about the internal operations of the company, such as products that are under development.

Footprinting often occurs when zone transfers are not secured and the attacker is able to perform a name dump from authoritative servers using the nslookup command with the ls option or the dig command with the afxr option—both of these commands initiate a zone transfer from the target domain.

To mitigate the risk from footprinting, it is important to ensure that zone transfers are secured. At the very least, zone transfers should be allowed to only a predetermined list of IP addresses that can be configured in the properties of the primary zone on the DNS server, as shown in Figure 6.20. You should also remember to secure your secondary name servers from unauthorized zone transfers, not just your primary server. Keep in mind that a secondary name server can also transfer zone information. However, even this configuration is vulnerable. For maximum security of zone transfers, you should ensure that zone transfers occur only within Active Directory-integrated zones. If you must transfer zone information over the Internet, you should also consider the use of VPN tunnels or IPSec to secure this traffic.

click to expand
Figure 6.20: Configuring a Primary Zone with a List of Secondaries Authorized to Do Zone Transfers

Redirection

A redirection attack occurs when an attacker is able to modify DNS records to redirect Web server or other traffic to servers under the attacker’s control. This attack occurs when an attacker is able to write information to the zone file. For example, this might happen if dynamic updates are enabled on a zone that is located on an Internet-facing DNS server. For this reason, it is always prudent to disable dynamic updates on zone files that are accessible to clients on the Internet.

Another common cause of redirection attacks is cache pollution (also called cache poisoning). Cache pollution can occur when a DNS server queries another DNS server and receives a reply from the queried DNS server that is outside the domain namespace in the original query. Unless countermeasures are taken, the DNS server will store this referral information in its cache, even though it did not originally request the information. For example, suppose that your DNS server issues a query for the MX record in the sampledomain.com domain. The authoritative DNS for the sampledomain.com server responds with the MX record, but it also replies with a bogus record for a.root-servers.net, listing its own IP address for the A record. Your DNS server now has a bogus record for a root-level DNS server in its cache.

DNS servers are vulnerable to cache pollution if an answer to a DNS query can be falsified. The consequences of cache pollution can be severe. Imagine what might happen if the poisoned cache of a DNS server redirected users to bogus Web site that contained malicious code designed to install Trojan viruses on client computers.

When cache pollution protection is enabled, the DNS server will discard from its cache the records it receives in response to queries if those responses contain information unrelated to the domain subtree of the requested resource. In our example, if protection against cache pollution is enabled, the DNS server will cache the MX record for the mail server in sampledomain.com, but will not cache the record for the a.root-servers.net, since it is not part of the queried domain subtree. Cache pollution protection is a DNS server-wide setting (Secure cache against pollution) and is enabled by default on Windows Server 2003 DNS servers (see Figure 6.15 earlier in this chapter).

Another way to mitigate the risk of cache pollution is to disable recursion on the DNS server. An attacker can use recursion to query the DNS server for resources in the attacker’s domain. The recursive name server is then forced to query DNS servers in the attacker’s domain that might attempt to pollute the cache of the recursive server.

DoS Attacks

A DoS attack occurs when a DNS server is deliberately flooded with traffic to the extent that it cannot respond to legitimate requests. DoS attacks on a DNS can be in-band on UDP and TCP port 53 (the ports used for DNS queries and zone transfers), or they can be out-of-band. In the case of an in-band attack, DNS servers are flooded with recursive queries to the extent that they become unable to handle legitimate queries, or the DNS service is subjected to a buffer overflow attack specific to the DNS service. In an out-of-band DoS attack, the DNS server is the victim of an attack that is not specific to the DNS service, such as buffer overflow, SYN, and Smurf attacks. When a DoS attack occurs on a DNS server, mail servers and Web servers become unavailable as well because the host names for these servers cannot be resolved to IP addresses.

One approach to mitigate the risk of DoS attacks against your DNS server is to eliminate single points of failure by having multiple DNS servers that are located on separate subnets served by separate routers. Also, you can arrange to have secondary servers hosted offsite by a third party, such as your ISP.

Note

Recently, Microsoft’s own DNS servers were the victims of a DoS attack that made a number of Microsoft Web sites inaccessible. The reason that Microsoft’s DNS servers were vulnerable is that all of them were placed in the same physical location behind a single router, hence exposing a single point of failure.

To provide further protection against in-band DoS attacks, you can disable recursion on Internet-facing DNS servers. Recursive queries take a relatively long time to process, making a DNS server that performs recursion vulnerable to a DoS attack that involves sending a large number of recursive queries to the DNS server. When you disable recursion on a DNS server, it will not respond to recursive queries issued by DNS clients. DNS clients will not be able to use this server to resolve names on the Internet. However, the DNS server will still respond to iterative queries issued by other DNS servers. This means that it will respond to queries for resources in zones for which it authoritative.

Recursion is a server-wide DNS setting and is enabled by default. (You can also disable recursion for forwarding servers on a per-domain basis.) If you disable recursion for the entire DNS server, you will not be able to use that DNS server as a forwarder. You can see the Disable recursion (also disables forwarders) option in Figure 6.15, shown earlier in the chapter. On internal DNS servers, it is often not desirable to disable recursion. In this case, these DNS servers need to be protected by firewall access rules that prevent their use by DNS clients on the Internet.

To provide further protection against both in-band and out-of-band DoS attacks, it is important to ensure that you apply the latest service packs and harden the servers as much as possible. In addition, your firewall access rules and packet filtering should be configured to prevent any external traffic that is not related to the DNS service from reaching the DNS server. For example, a firewall that is in front of a DNS server in a DMZ should allow traffic to reach the DNS server only on TCP and UDP port 53.

Securing DNS Deployment

In the preceding section, we identified some of the common threats to the DNS infrastructure and provided a number of countermeasures such as securing zone transfers, disabling recursion, and enabling protection against cache pollution. However, securing a DNS infrastructure requires more than just fine-tuning settings of the individual DNS servers.

Securing the DNS infrastructure starts with the design and implementation of your DNS namespace, and continues with the implementation and configuration of the DNS servers themselves, along with the implementation and configuration of firewalls, routers, and other network devices that can serve to protect individual servers and the network itself. It is possible, for example, to use a private root zone on your intranet and tightly control DNS query access to the Internet. Using a private root in combination with a DNS security policy that restricts DNS queries to the Internet can result in enhanced security for your organization.

DNS Security Levels

To assist in the secure deployment of a DNS infrastructure, Microsoft has published guidelines on its Web site and within the Windows Server 2003 help files that categorize three basic levels of DNS security: low level, medium level, and high level. In the following sections, we will discuss each level in more detail. In considering these models, you should assume that they represent a set of ideal guidelines for the purposes of conceptualization and example. Many organizations do not want to slavishly abide by the models in their purest form.

Low-level DNS Security

The low level of DNS security is precisely that: low. In fact, some of the default security configurations of DNS are removed entirely. The effective security is none at all. As the Windows Server 2003 help files state, this kind of configuration should be used only when there is no concern for the integrity of your DNS data or there is no threat that the DNS data on a private network is accessible from the Internet. The characteristics of low-level security are as follows:

  • The DNS infrastructure is fully exposed to the Internet.

  • All the DNS servers in your network use standard DNS resolution.

  • All DNS servers are capable of performing queries to the Internet using root hints that point to the root servers for the Internet.

  • Zone transfers are allowed to any server, which represents a removal of the default setting to allow zone transfers only to servers listed in the Name Servers tab.

  • The default setting to prevent cache pollution is disabled on the DNS server.

  • Multihomed DNS servers (servers with multiple IP addresses) are configured to listen for DNS queries on all configured interfaces.

  • All zones are configured to accept dynamic updates from DNS clients.

  • UDP and TCP port 53 are open on the firewall for both the source and destination address (that is, the firewall allows any DNS traffic to traverse your firewall, regardless of whether it is initiated by an external or an internal host).

Some organizations may have such a deployment; however, it would be extremely unwise to deploy something like this yourself. Turning off cache pollution protection, in particular, exposes your DNS infrastructure to an unacceptable level of risk, relative to the cost of leaving the default configuration enabled.

Medium-level DNS Security

The medium level of DNS security takes advantage of the countermeasures that are available in a DNS infrastructure where zone data is stored in standard primary or secondary zone files. The security features available through Active Directory-integrated zones are not employed here. The characteristics of medium-level security are as follows:

  • Exposure of your DNS infrastructure to the Internet is minimized.

  • Internal DNS servers are configured to use a limited list of forwarders when they cannot resolve names locally.

  • The default configuration to limit zone transfers to DNS servers listed on the Name Servers tab is left in place.

  • In the case of multihomed DNS servers, the DNS servers are configured to listen on only specified IP addresses.

  • The default setting to prevent cache pollution is left in place.

  • No dynamic updates are allowed on any zones.

  • The firewall is configured to limit the traffic traversing the firewall to a limited set of source and destination addresses. Only the external DNS servers under your control are allowed to communicate with internal DNS servers.

  • Only the external DNS servers in front of your firewall are configured with root hints to perform recursion.

  • All name resolution required by a host on your internal network is performed by proxy servers or gateways.

This represents a more reasonable and prudent approach to mitigating risk to the DNS infrastructure than is offered by the low level, with a low cost of implementation relative to the advantages gained.

High-level DNS Security

A high-level security policy starts with the medium-level security policy and further enhances security by leveraging the security available with Active Directory-integrated zones. Furthermore, the high-level security policy assumes that there is no DNS communication with the Internet. This is an unlikely configuration but something like it might be implemented by organizations that have strict security requirements, and the risk of connectivity to the Internet is deemed to be too great. The characteristics of a high-level security policy are as follows:

  • No DNS communication is allowed between the Internet and internal DNS servers.

  • The internal DNS infrastructure deploys a private, internal root namespace and is authoritative for all zones.

  • The root hints file on all DNS servers points to only the IP addresses of the internal DNS servers that are authoritative for the private root zone.

  • Zone transfers are limited to specific IP addresses, rather than just servers listed on the Name Server tab.

  • DNS servers are configured to listen on specific IP addresses.

  • All DNS servers run on domain controllers, with discretionary access control lists (DACLs) configured to allow only specific authorized individuals to perform administrative tasks on the DNS servers.

  • All DNS zones are configured as Active Directory-integrated zones, with DACLs configured to allow only specific authorized individuals to create, modify, or delete DNS zones.

  • All RRs stored in Active Directory-integrated zones have DACLs to allow only specific individuals to create, delete, or modify zone data.

  • No dynamic updates are allowed on the root and top-level domains.

  • Only secure dynamic updates are allowed on the child domains.

For many organizations, none of these models will be adequate. The cost, for example, of not allowing DNS communication with the Internet, and expense of connectivity, might be too great. The reality is that many organizations will want to develop and deploy a DNS security model that is hybrid of the medium-level and high-level security models.

General DNS Security Guidelines

In planning for the security of your DNS infrastructure, you will want to take into account the design of your DNS namespace, the number and type of DNS servers and zones you plan to deploy, and whether the DNS servers will be serving internal or external clients. You will also want to take into account the security already present or needed in your current infrastructure, such as the location, type, and configuration of firewalls that protect your network.

In most cases, it is desirable to maintain a set of DNS servers that serve the internal network only and a separate set of external DNS servers that allow DNS clients on the Internet to be able to resolve the names for your Web, mail, and other publicly available servers. Each set of DNS servers would have different security configurations, depending on their role. Furthermore, it is desirable to further enhance security of these two sets of DNS servers by maintaining either a split DNS configuration if you choose to use the same namespace for the intranet and Internet, or a split DNS namespace for the intranet and Internet. If your internal namespace includes a private root zone, you can further enhance the security of the DNS infrastructure.

Security Guidelines for an External DNS Infrastructure

Integrity and availability of DNS data are primary considerations for an external DNS infrastructure, and your design should be informed by these considerations:

  • Place all DNS servers in a DMZ or a perimeter network to ensure that access rules and packet filtering on firewalls and routers tightly control source and destination addresses and ports. If possible, configure single-purpose DNS servers and allow traffic on only UDP and TCP port 53 to reach these servers from the Internet.

  • Uninstall all unnecessary services from these servers, install current service packs, and harden the servers as much as possible.

  • Eliminate single points of failure by hosting DNS servers on different subnets served by different routers. Consider hosting a secondary server at your ISP, for example. This will help mitigate the risk of DoS attacks.

  • Consider using a stealth primary server to update read-only secondary servers that are registered with ICANN.

  • Allow zone transfers to only a specific set of IP addresses and consider using IPSec or VPN tunnels to enhance the security of zone transfer traffic.

  • Do not enable dynamic updates on Internet-facing DNS servers.

  • Enable protection against cache pollution on Internet-facing DNS servers.

  • Disable recursion on Internet-facing servers.

  • Regularly monitor DNS logs and Event Viewer.

Security Guidelines for an Internal DNS Infrastructure

Confidentiality, integrity, and availability of DNS data are primary considerations for an internal DNS infrastructure. The following are security guidelines to consider:

  • Consider using a separate, internal namespace to enhance security.

  • Do not allow external access from the Internet to your internal DNS servers.

  • Consider using a proxy server or a gateway to manage Internet DNS requests for internal clients.

  • Use Active Directory-integrated zones and allow only secure updates to these zones.

  • Specify and limit the servers that are able to receive zone transfers.

  • Eliminate single points of failure and consider how internal DNS clients will resolve names in the event that the primary DNS server in their TCP/IP configuration fails.

  • Consider that delegating authority of child domains can involve a security trade-off if different administrators are responsible for the authoritative DNS servers.

start sidebar
Configuring & Implementing...
DNS Ports

For configuring firewall access rules, keep in mind that DNS uses both TCP port 53 and UDP port 53 for DNS communications. UDP is generally used for normal query traffic, whereas TCP is used for zone transfers. However, if the DNS server cannot deliver a response to the query using UDP because the response is too large, it will ask the resolver to switch to TCP port 53. This should occur only rarely (or never) if the DNS records are properly configured. The most common cause is an excessive and improper use of records used for round-robin name resolution or an excessive number of name server records.

You can use EDNS0 (discussed earlier in this chapter) to increase the default size for UDP packets. However, you would want to do this on your internal network, not the Internet. If you want to load-balance your Internet Web servers, you might want to consider using NLB or a third-party product such as BigIP from F5. In any event, it should be safe to block inbound traffic on TCP port 25 to prevent zone transfers from all but authorized DNS servers.

end sidebar

Monitoring DNS Servers

An important task in maintaining a DNS environment is monitoring the DNS servers to ensure that they are resolving names and IP addresses properly, and to ensure that they have sufficient resources to handle their workload. Windows Server 2003 and the Windows Server 2003 DNS service provide a number of tools for monitoring DNS servers. These tools include the Monitoring tab on the DNS console, DNS debug logging, DNS event logging, and DNS Performance Monitor counters, as well as command-line tools such as NSLookup.exe, Dnscmd.exe, and DNSLint.exe. In this section, we will briefly cover the use of these tools to monitor a DNS server environment.

Testing DNS Server Configuration with the DNS Console Monitoring Tab

The DNS console provides a simple but effective tool for ensuring that the DNS service is working properly. To use this tool, click the Monitoring tab of the properties for the DNS server, as shown in Figure 6.21.

click to expand
Figure 6.21: Performing Simple and Recursive Queries Using the Monitoring Tab of the DNS Server Properties

The Monitoring tab allows you to perform a simple and a recursive query test to ensure proper operation. A simple query test uses the DNS client installed on the DNS server to send a local query to the DNS server. A recursive query test uses the local DNS client as well. However, in this case, the DNS client requests that the DNS service use recursion to resolve an NS-type query for the root zone. Failure of this test usually indicates a problem with network connectivity or incorrectly configured root hints. (In the example in Figure 6.21, the recursive query test failed because the network adapter was unplugged before the test was run, and the DNS server could not connect to the servers listed in the root hints file.) When a DNS server fails one of these tests, a warning symbol is displayed on the DNS server in the DNS console. Note that you can set up automatic simple and recursive query testing in the Monitoring tab. It is a good practice to use these tests after you have set up a DNS server or have made a configuration change on a current DNS server.

Debug Logging

If you need to analyze and monitor the DNS server performance in greater detail, you can use the optional debug tool that you can enable in the Debug Logging tab of the DNS server property pages. Because debug logging consumes significant resources, it is not enabled by default and should be enabled only on a temporary basis, such as when you’re trying to troubleshoot a problem with DNS. Figure 6.22 shows the configurable properties for DNS debug logging.

click to expand
Figure 6.22: Debug Logging Properties

As you can see in Figure 6.22, you have a lot of flexibility and control with regard to the filtering of DNS traffic you wish to include in the debug logs. You can choose to log packets based on the following:

  • Their direction, either outbound or inbound

  • The transport protocol, either TCP or UDP

  • Their contents: queries/transfers, updates, or notifications

  • Their type, either requests or responses

  • Their IP address

Finally, you can choose to include detailed information.

Let’s assume you were trying to troubleshoot a problem with dynamic updates. You could configure the debug utility to log any update packets but exclude queries/transfers and notifications. This configuration would exclude information that isn’t relevant to the problem. You could further refine the information contained in the logs by monitoring for either requests or responses or for incoming or outgoing packets.

Depending on the amount of DNS traffic the server processes and the logging options you select, the log files can grow quite large. You should configure logging to occur on a separate hard drive. When the log file reaches the maximum size or the hard drive runs out of room, newer events will overwrite older events.

Event Logging

By default, the DNS service will log all DNS events to the DNS Event log. In Windows Server 2003, DNS events are kept in a separate system event log that can be accessed from either the DNS console or Event Viewer. The Event Logging tab on the properties of the DNS server allows you to configure the events you would like to log in the DNS Event log. There are four options on the Event Logging tab: No events, Errors only, Errors and warnings, and All events. The default is to log All events, which include informational messages that indicate service startup, a new version number for a zone file, and so on. On a busy DNS server, the default size of the event log might not be large enough. You should consider increasing the size of the DNS Event log in this case.

Monitoring DNS Server Using the Performance Console

The Windows Server 2003 Performance console provides a means of monitoring DNS performance, either in real time through the System Monitor or as events logged over a period time by Performance Logs. When the DNS service is installed on Windows Server 2003, more than 60 performance counters are installed for measuring performance of the DNS service. Figure 6.23 shows some of the DNS performance counters that you can select in System Monitor.

click to expand
Figure 6.23: DNS Performance Counters

Because the DNS is a critical service, you should log its performance over a period of time using Performance Logs to establish a baseline for normal operating conditions. Once you’ve established a baseline, you can then use this information to predict effects of planned changes to the infrastructure, such as adding or removing other DNS servers or adding more DNS clients. Performance baselines also help you to optimize services on your network by providing real-world data about the performance of your servers and your network.

Having a baseline also allows you to detect and troubleshoot problems with your DNS and network infrastructure. For example, if the number of Secure Update Failures suddenly increased, you might be prompted to investigate further to determine the cause of the problem.

In choosing DNS counters to monitor, you should consider the role(s) of the DNS server:

  • If the DNS server is installed on a domain controller and configured for secure only updates in Active Directory-integrated zones, you should monitor counters that are relevant to dynamic updater performance and security, such as Secure Update Failure, Dynamic Update Written to Database/sec, Dynamic Update Received/sec, and so on.

  • If the DNS server is used to perform recursion on behalf of clients, you should monitor counters that are relevant to the performance of recursive queries, such as Recursive Queries/sec or Recursive Query Failures/sec. If you have disabled recursion on your server, a spike in the number of recursive queries the DNS server receives could warrant further investigation.

  • If the DNS server replicates zone data with other servers, either as a primary or secondary server, you should monitor counters relevant to zone transfers, such as AFXR Requests Received, which would indicate that a number of secondary DNS servers are requesting a full, rather than incremental, zone transfer. A sudden increase in the number of zone transfer requests could indicate the presence of an attacker trying to footprint your DNS records.

    Exam Warning

    Microsoft exams will not test you on how to use utilities. Rarely does the test candidate need to remember commands and switches. However, many questions that you encounter are often informed by an understanding of the capabilities of a particular utility. The Performance Monitor counters are no exception. Often, your ability to answer a question correctly will depend on your understanding of the capabilities of the utility.

Command-line Tools for Maintaining and Monitoring DNS Servers

Windows Server 2003 provides three command-line utilities for maintaining and monitoring DNS servers:

  • NSLookup This is a standard tool used for monitoring and troubleshooting DNS servers. It provides a means to obtain detailed results for queries performed against a DNS server. NSLookup has two modes: interactive and noninteractive. Interactive mode allows you enter more than one command at an NSLookup prompt. Noninteractive mode is invoked as a single command with options from a command prompt. For NSLookup to work properly, the DNS server that NSLookup is pointing to must have a PTR record for it in a reverse lookup zone.

  • Dnscmd This utility is found in the \Support\Tools folder on the Windows Server 2003 installation CD. The Dnscmd tool can be used as an alternative to the DNS MMC. With DNScmd, you can create and delete zones, view records, update zone records, and perform other administrative tasks that you would normally perform using the DNS console. Dnscmd can be used to script batch operations and perform remote administration, providing an efficient way to manage multiple, remote DNS servers.

  • DNSLint This utility is found in the \Support\Tools folder on the Windows Server 2003 installation CD. DNSLint is new to Windows Server 2003. Its primary purpose is to assist in troubleshooting problems arising from lame (incorrect) delegations and common AD DNS problems, such as verifying records for AD replication. A key advantage of the tool is that it can examine multiple servers in a single operation and display the output as an HTML file. For example, if you were trying to troubleshoot a problem with delegation, you would need to traverse the DNS namespace in multiple steps. With DNSLint, you can diagnose the problem in a single operation. You can also use DNSLint with the /c switch to test well-known e-mail ports on all e-mail servers that it finds in the zone records of the DNS servers it checks in the domain.

These tools can be used for a variety of purposes, such as verifying the presence of RRs, checking for lame delegations, checking for missing AD replication records, configuring DNS server settings on multiple servers, and so on.




MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure. Exam 70-293 Study Guide and DVD Training System
MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure: Exam 70-293 Study Guide and DVD Training System
ISBN: 1931836930
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net