Designing a DNS Name Resolution Strategy

Windows Server 2003 requires a sound DNS infrastructure in order to operate at all. This was not true of Windows NT, which could function without DNS by using NetBIOS. Windows Server 2003 and Windows 2000 replace NetBIOS name resolution with DNS name resolution and SRV records. SRV records are service records that are stored in the DNS database and indicate which service each server brings to the network. Without SRV records, the network would not know its own members and each one's function in the network. Because these SRV records are proprietary to each network, they should never be exposed to the Internet. This requires a firewall and a functional and secure DNS namespace design.

The DNS namespace typically comes from the name of the organization, but administrators have three basic choices in regard to namespace design:

• Use the same name on the outside of the firewall as on the inside

• Delegate a subdomain for the inside of the firewall

• Use a completely different name on the inside and the outside of the firewall

Each of these choices has its advantages and disadvantages. For example, let's consider a company named widgetsinc.com. We'll examine each of its options and highlight the advantages and disadvantages of each choice.

First, if the administrators choose to use widgetsinc.com on the inside and the outside of the firewall, there would be no confusion about the name and no training would be necessary. On the other hand, the administrators would need to make sure that they kept only the public records on the DNS servers that are on the outside of the firewall, and never let the servers replicate the SRV records from the inside to the outside.

As an alternative, the administrators could use a delegated subdomain on the inside of the firewall. In that case, they might use ad.widgetsinc.com. This would in effect separate the records so that the inside of the firewall and the outside were two different, yet connected, databases. This would require less concern for security, but might require a little training to explain to users the small difference in the names if they are accessing the network from inside the firewall as opposed to from the outside.

The third option would be to use a completely different name. In this case, the administrators might use gadgets.com on the inside and widgets.com on the outside. This would be the most secure because none of the records associated with gadgets.com would ever be exposed to the Internet. It would also require the most training and explanation to make sure that the users can access the information that they need from inside the network as well as from outside. Table 5.1 illustrates each choice and its advantages and disadvantages.

Table 5.1. Namespace Design Choices

Design Choice	Advantages	Disadvantages
Same name	No training necessary	Low security Needs constant firewall
Delegated subdomain	Higher security Familiar name for users	Some training for users Not most secure method
Completely different name	Highest security	Most training required Confusing to users Potentially more DNS servers required

DNS is extremely important to a network, but it is only one of the services in the network. There are many other services with which DNS must interoperate. These include Active Directory, WINS (Windows Internet Name Service), and DHCP (Dynamic Host Configuration Protocol). All Windows 2003 and Windows 2000 DNS servers can interoperate with Active Directory, but not all DNS servers can. Some BIND servers do not support Active Directory. This must be addressed as part of an overall DNS strategy.

A DNS server must be able to use SRV records to interoperate with Active Directory. This leaves out any version of BIND (Berkeley Internet Name Domain) server earlier than 4.9.7. In addition, BIND servers should be at least version 8.2.1 to take advantage of incremental zone transfers and dynamic updates.

DNS will continue to work with WINS as well. WINS is still necessary as long as the network has any legacy clients and/or applications these will still register with and use WINS. DNS can be configured to use WINS lookup when a hostname is not found in the DNS database. The underlying premise is that the hostname computer1.widgets.com should have the same IP address as the computer with the NetBIOS name computer1. You can configure DNS for WINS lookup as shown in Figure 5.1.

Figure 5.1. You can configure DNS for WINS lookup.

DHCP will also interoperate with DNS. When a client comes on to a network and receives an IP address from the DHCP server, that client and the DHCP server both know the address that was just given out. Therefore, either one can give this information to the DNS server.

Not all clients can register their own addresses; only clients that are Windows 2000 Professional and later can. You can set the DHCP server to register addresses for the clients that cannot register their own or for all clients. This design choice will depend on the types of clients in your network. Figure 5.2 shows the configuration settings in DHCP server for dynamic DNS. You must also enable dynamic DNS in the properties of the zone, as illustrated in Figure 5.3.

Figure 5.2. You can configure the DHCP server for dynamic DNS.

Figure 5.3. You can configure DNS zones for dynamic DNS.

DNS databases are organized in zones. A zone is a discrete, contiguous portion of a DNS namespace. In other words, it is set apart from all other zones, but it is a continuous hierarchy of an intranet or Internet namespace. Windows Server 2003 provides for four different types of zones:

• Standard primary

• Standard secondary

• Active Directory integrated

• Stub

Each type of zone has its advantages and disadvantages. For effective network design, it's important to understand how all of these types work individually as well has how they work with each other. Let's now examine each of these types of zones and their relation to the network.

Adding the words database file to the word zone sometimes helps tremendously in the overall understanding of zones. We use this technique during our examination of zones.

Standard Primary Zones

A standard primary zone database file is the original database of a zone. It can be read from and written to as well. The word standard indicates that it is not an Active Directory integrated zone. The zone database file contains a Start of Authority (SOA) record that sets the interval at which the standard secondary zones contacts it for changes in the zone. The administrator can make these changes manually or they can be made by dynamic DNS.

Servers that host standard primary zones can be master servers for other servers that host standard secondary zones. In addition, server hosting a standard primary zone can be a master server for many standard secondary zones. Servers that do not host a primary zone cannot be a master server. Standard primary zones communicate changes to standard secondary zones through zone transfer. Zone transfer can be bandwidth intensive, especially on slow links. An important part of DNS design is understanding and working within bandwidth limitations in regard to zones.

Standard Secondary Zones

A standard secondary zone database file is a copy of a standard primary zone database file. It can be read from, but it cannot be written to manually or by dynamic DNS. The only way that a standard secondary zone database file receives changes is by zone transfer.

The primary purpose of a standard secondary zone database file is to provide for load balancing in a network with many clients. Some clients can be set to the IP address of the server with the standard primary zone database file, and others can be set to the IP address of the server with the standard secondary zone database file.

A standard secondary zone database file provides some short-term fault tolerance for name resolution, but it cannot be considered a long-term option for fault tolerance. The SOA record on the master server with the standard primary zone controls the period of time that a standard secondary zone can still resolve queries if the master has failed. This is typically set no higher than one day.

Standard secondary zones do not provide fault tolerance and should not be used if fault tolerance is a key concern. Active Directory integrated zones would likely be used in this situation.

Active Directory Integrated Zones

An Active Directory integrated zone database file has many advantages over a standard zone database file, but it cannot be used on all servers. Changes to an Active Directory integrated zone database file are replicated to all other DNS servers that host the same zone database file by piggy-backing on normal Active Directory replication. To make this possible, all DNS servers that host Active Directory integrated zones (zone database files) must also be domain controllers. This eliminates zone transfer between Active Directory integrated zones. An argument can be made that the zone transfer information is contained in the Active Directory replication; however, this is not technically referred to as zone transfer.

Active Directory integrated zones provide long-term fault tolerance. This is because all Active Directory integrated zones are primary zones. In other words, they can be written to and read from as well. In addition, Active Directory integrated zones can be secured. You can set Active Directory integrated zones to accept updates from only specific users and computers. This is referred to as setting Secure Only updates. Figure 5.4 illustrates how to configure a zone for Secure Only updates.

Figure 5.4. You can configure a zone for Secure Only updates.

Active Directory integrated zones are preferred when minimizing zone transfer is a key concern. Because the replication between Active Directory integrated zones occurs with Active Directory replication, there is said to be no zone transfer at all with Active Directory integrated zones.

Stub Zones

A stub zone database file is a special type of zone that is new to Windows Server 2003. It is a read-only copy of a zone database file. The major difference between a stub zone database file and a standard secondary zone database file is that the stub zone's database file contains only the records that are necessary to define the server itself. A stub zone database file keeps the servers that are hosting parent zones aware of the servers that are hosting child zones (delegated sub-domains). It does this without replicating all the records in the zone database file, thereby maintaining both name resolution efficiency and bandwidth efficiency.