Designing a DNS Namespace 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 cus- tomers and for the smooth and secure operation of its network.You should take some of the fol- lowing considerations into account: ■ Uniqueness Domain names on the Internet must be unique. 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. ■ Security Designing a DNS namespace should take into account the security require- ments 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. ■ 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 orga- nization’s public Web servers. Host Naming Conventions and Limitations Regardless of the choice you make for the domain namespace of your internal and external net- works, 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 666 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 666 lowercase (it is an optional requirement that case be preserved for use with DNS; to ensure max- imum compatibility Microsoft does not implement the optional requirement for case preservation). In other words, all uppercase characters will be treated as lowercase characters. 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. 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 environ- ments 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. The Underscore Character While it is legitimate to use the underscore character in NetBIOS names, the inclusion of this char- acter 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) As a prerequisite to installing AD, you must first have a DNS infrastructure in place on your net- work 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 ser- vices 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 Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 667 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 667 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 infrastruc- ture 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. 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. 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 namespaces. 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 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 con- figuration, 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 avail- able 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 man- aging 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 com- pletely 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 668 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 668 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. 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 names- pace 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 names- pace, making it easier for users to connect to these resources. ■ Any DNS records used for AD are isolated in the child domain and its subdo- mains.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. 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 auto- matically 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, Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 669 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 669 when a DNS server encounters a query request for name resolution for resources in a sep- arate 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 spe- cial 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 speci- fied 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 authorita- tive 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 man- ually 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 infrastruc- ture, 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. 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.syngress.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 sim- plify your DNS infrastructure. 670 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 670 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 20.2 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 dele- gation to a disjointed namespace (tacteam.net) to allow an internal DNS server to resolve host names on the tacteam.net network. Note that dns1.syngress.local does not perform Internet name resolution for client PCs.The ISA Server contacts a DNS server capable of performing name resolu- tion on the Internet. However, dns1.syngress.local, by virtue of a name server delegation, performs recursive DNS resolution for hosts in the tacteam.net network. In the example in Figure 20.2, a considerable amount of DNS name resolution traffic can cross a WAN link between the syngress.local and the tacteam.net networks.To reduce this traffic, you can host a secondary zone for tacteam.net on dns1.syngress.local and host a secondary zone for syn- gress.local on dns1.tacteam.net. In fact, in order for dns1.tacteam.net to perform name resolution for hosts on the syngress.local network, you must either host a secondary zone for syngress.local or use some other configuration, such as conditional forwarding, to make it possible for this name resolu- tion to occur. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 671 Figure 20.2 Deployment of a Private Root Zone ISA Server External DNS PC Client Dns1.shinder.local: Authoritative for private Root and Shinder.local zones Internet Internet Root DNS Server PC Client Dns1.tacteam.net: Authoritative for Tacteam.net Name Server Delegation for Tacteam.net 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 671 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 loca- tion 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 char- acter 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 infrastruc- ture 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 672 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 672 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 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 net- work 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. Planning for DNS Server Capacity 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. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 673 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 673 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. 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 In 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 config- ured 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 what 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 con- sumes too much bandwidth, consider using forwarding servers in the remote location. 674 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 674 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 informa- tion 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 con- figured 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 sec- ondary 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 is currency of records, since updates from the primary DNS server must travel through more than one secondary server before all the records are syn- chronized 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 replica- tion 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. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 675 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 675 . 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. 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. 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