Managing the Directory

Like this article? We recommend

Windows 2000 Essential Reference

Learn More Buy

Like this article? We recommend

Like this article? We recommend 

Windows 2000 Essential Reference

Learn More Buy

4.2: DNS and Active Directory

The DNS Namespace

Previous versions of Windows NT were built on NetBIOS. To provide name resolution services for NetBIOS over the Transmission Control Prococol/Internet Protocol (TCP/IP), the Windows Internet Name Service (WINS) was created. This allows you to resolve 16-character NetBIOS names to Internet Protocol (IP) addresses.

For more information on the Windows Internet Name Service, see Chapter 8.4, "Windows Internet Name Service (WINS)."

One of the chief designs of Windows 2000 is the removal of the dependency on NetBIOS. The designers of Windows 2000 made the decision to move to a pure IP implementation. To provide name resolution services in Windows 2000, the Internet Engineering Task Force (IETF) standard Domain Name System (DNS) is used.

DNS is a hierarchical naming system. Names in DNS are composed of host names and Domain names. The Domain names consist of a series of names separated by periods (for example, na.mycompany.com). There are two fundamental principles to the DNS namespace. First, each child can have only one parent. Second, each parent can have only one child with any given name. This works the same way as the file system on your PC. Every file can exist only in one directory and the filename must be unique in that directory.

For more information on DNS and name resolution, see Chapter 8.3, "Domain Name System (DNS)."

In Windows 2000, all Domains and the computers in those Domains must have DNS names. Additionally, several key services register names. Chapter 1.2, "Introduction to Active Directory," provides an introduction to these concepts, including Domain Controllers and Global Catalog Servers. These service records are extremely important for the proper functioning of the Active Directory. In Windows 2000, these records are generally used for one of these three things:

• Creating the replication topology for the Active Directory. The Knowledge Consistency Checker (KCC) uses specific DNS records to create the replication topology.

For more information on Active Directory Replication, see Chapter 4.3, "Configuring a Domain Controller."

• Finding the location of Windows 2000 Domain Controllers and Global Catalog Servers. Windows 2000 clients use these records to find the appropriate Domain Controller or Global Catalog Server, based on that servers proximity to the client.

• Finding the location of standard Kerberos services. Because Windows 2000 can provide standard Kerberos services to non-Windows 2000 clients, these records are important to ensure that those clients can find the correct servers. Examples of these records include the Kerberos Password Change servers and the Key Distribution Centers.

With two exceptions, Windows 2000 Domain names must follow all of the rules of DNS discussed previously. First, Microsoft's implementation of Windows 2000 DNS allows DNS names to contain UTF-8 characters. The UTF-8 character set is a superset of ASCII, as described in IETF RFC 2044. This was done to maintain compatibility with NetBIOS names used in Windows NT. Additionally, the UTF-8 character set includes support for most languages. Second, the DNS name of a Windows 2000 Domain cannot exceed 64 characters. This maximum was implemented due to a underlying limitation on DNS and UNC name lengths.

In order to understand and design the DNS namespace to support your Active Directory implementation, you should follow these three steps:

1. Understand your current DNS namespace.

2. Plan your Active Directory based on your organizations needs.

3. Create the additional DNS zones required to support the Active Directory.

Step 1: Understand Your Current DNS Namespace

Before designing your Active Directory implementation, you need to understand your existing DNS namespace. First, you need to know whether your organization even has an existing DNS namespace. Most companies will have some sort of DNS implementation in their current environment. Second, you need to know the names and hierarchy of the current environment. Finally, you need to know if this is a public (published on the Internet) or private namespace.

Figure 4.2.1 shows an example of a simple DNS namespace. Mycompany has an external namespace of mycompany.com with sub-domains of phx (Phoenix) and bos (Boston). Some of the machines in Phoenix and Boston need to be available on the Internet (public namespace).

Figure 4.2.1 Example of current DNS namespace.

Step 2: Plan your Active Directory Based On Your Organization's Needs

Now that you understand your organization's existing DNS namespace, it is important to begin planning for your Active Directory. Some of the most basic questions that you need to answer include "How many Domains will I need?" and "What will their names be?" It is recommended that you do not overlap with your existing DNS structure. Some of the most common implementations either create a completely separate namespace from your existing DNS implementation or simply delegate a sub-domain that will become the Active Directory's forest root.

For more information on analyzing your current environment and planning your Active Directory, see the Deployment Planning Guide that comes with the Microsoft Windows 2000 Resource Kit.

Figure 4.2.2 shows an example of Mycompany's planned Active Directory. They will implement two Domains:

• corp.mycompany.com: The root of the Windows 2000 forest.

• na.corp.mycompany.com: A single Domain for all users and computers in North America.

Figure 4.2.2 Example of Active Directory implementation

Step 3: Create the Additional DNS Zones Required to Support the Active Directory

The final step is also the easiest. After you understand your current DNS namespace and have planned your Active Directory, you should simply create the appropriate DNS zones.

Figure 4.2.3 shows an example of the DNS zones required to support Mycompany's Active Directory shown in Figure 4.2.2. DNS zones need to be created for corp.mycompany.com and na.corp.mycompany.com. By creating these zones separate from the existing PHX and BOS zones, you are able to keep your existing machines in the public namespace without needing to publish your Active Directory zones on the Internet.

Figure 4.2.3 Example of DNS zones supporting the Active Directory.

The DNS Resource Records

A resource record is simply an entry in the DNS database. Resource records map the names of servers or services to their location, much the way that the Windows Internet Name Service (WINS) did in previous versions of Windows NT. This referenced location can be either the physical Internet Protocol (IP) address or the name of the server.

Table 4.2.1 lists some of the common resource record types that you will encounter in Windows 2000.

Table 4.2.1 Common DNS Resource Record Types

Default Records Registered by a Windows 2000 Domain Controller

Because the Windows 2000 Active Directory is built on TCP/IP, Domain Controllers register several records in the DNS database. Mainly, these are Service Locator (SRV) records. These records allow clients to find the location of services, such as Domain Controllers, Global Catalog servers, Light-weight Directory Access Protocol (LDAP) Servers, and Kerberos Key Distribution Centers.

Table 4.2.2 lists the DNS records that are registered by the Netlogon service on Windows 2000 Domain Controllers.

Table 4.2.2 DNS Records Registered by Windows 2000 Domain Controllers

The Netlogon service registers several records that may seem redundant. However, the Windows 2000 Active Directory was designed around industry standards (Kerberos, X.500, and so on). This allows the Active Directory to interoperate with many operating systems and applications. These records are required to maintain this level of interoperability.

Storing DNS Information in the Active Directory

One of the most powerful features of Windows 2000 DNS is the capability to store DNS information in the Active Directory. If a zone is stored in the Active Directory, it is said to be "Active Directory-integrated."

In order for a zone to be Active Directory-integrated, the DNS service must be installed on a Windows 2000 Domain Controller. You can set the zone type to be an Active Directory-integrated primary zone by right-clicking on the zone, selecting properties, and setting the appropriate value in the DNS MMC snap-in. Once done, this zone will be created as a container in the Active Directory. For example, location in the Active directory of the zone mycompany.com (to support the Domain mycompany.com) would be mycompany.com\system\MicrosoftDNS\mycompany.com.

All of the resource records for that zone would then be stored as objects in that container.

After this data is stored in the Active Directory, there is no longer the need to set up zone transfers, as in standard DNS. These DNS objects are now replicated just like every other object in that Domain. Should you desire to replicate that zone to a member server or a server outside of the current zone, you can still set up a standard zone transfer. However, the server that the zone is being replicated to will treat that zone as a standard secondary zone. Clients cannot update records on a standard secondary zone. The clients need to send their update requests to the SOA for the zone. The SOA for that zone on the target server will point to the Domain Controller that the data was replicated from.

In addition to the simplification in replicating DNS data, there are other benefits of Active Directory-integrated DNS:

• Multi-Master Updates

• Secure Dynamic DNS

Multi-Master Updates

Standard Dynamic DNS allows only a single Start of Authority (SOA) record for each zone. All updates must occur on the SOA and are then replicated to the other DNS servers that house that zone.

This behavior, if not modified, would create a scalability issue for the Active Directory. As Domains get large in Windows 2000, it would not be optimal if all DCs, clients, servers, and services were required to update their DNS records through only one server. The DNS server that is the SOA would be a single point of failure for record updates.

However, if the DNS zone is stored in the Active Directory, this problem is solved. The Active Directory supports updates to objects on any DC. Because the DNS records are objects in the Active Directory, they support the multi-master behavior, as well. To allow this behavior within the confines of RFC 2136, which described Dynamic DNS, Windows 2000 allows each server to own the SOA for Active Directory-integrated zones that are installed on itself.

Secure Dynamic DNS

Another issue with standard dynamic DNS is that resource records are not protected. Only the last update to the resource record is reflected in the zone. This allows other servers or services to "steal" those records inadvertently, or, even worse, you could be susceptible to a denial-of-service attack.

To prevent these issues, an Active Directory-integrated zone can be configured to allow only secure updates. However, once enabled, only Windows 2000 systems can update that zone. Each record in the Active Directory is then ACLed with the SID of the system registering that record. Then, only that server, the system account, or an Administrator can modify that record.

Maintaining Zones in Windows 2000 DNS

With dynamic DNS, it is possible for records to be added to zones, but never deleted. Additionally, with the introduction of Secure Dynamic DNS, those records would be ACLed to the original owning server. If that server becomes unavailable, other servers are prevented from updating (or reusing) those records.

To solve these issues with dynamic DNS zones continuously expanding due to these stale records, Microsoft introduced the concept of aging and scavenging DNS records.

Aging and Scavenging is configured by setting parameters on both a per-zone and per-server basis. This allows you to specify which servers can scavenge which zones. Through careful planning, you can keep your zones clean and prevent having a server scavenge records that have been refreshed on, but not replicated from another server.

Table 4.2.3 Configurable Parameters for Aging and Scavenging DNS Records

If Aging and Scavenging are enabled, a record in that zone has a period of time during which refreshes cannot occur. This is the No Refresh interval. This interval prevents excessive replication due to a short duration between refresh attempts on the client.

Updates (changing the data in the record) can occur at any time, including during the No Refresh interval.

After the No Refresh interval has expired, the record has a period of time during which it will allow refreshes. This is the Refresh interval. After the record is refreshed by the client, the No Refresh interval starts over again. If, for some reason, the Refresh interval expires, the record will be deleted at the next scavenging.

If both the server and the zone are set to allow scavenging, scavenging will occur as dictated by the scavenging period on the server.

Using Third-Party DNS Servers with the Active Directory

Although it is physically possible, choosing to use a third-party DNS server can be quite an undertaking. Microsoft has added some key features to its DNS service that makes it better prepared to support the Active Directory. For example, support for the UTF-8 character set ensures that Windows 2000 will fully interoperate with your down-level NetBIOS names. Also, the addition of Secure Dynamic DNS provides you with a level of security against denial-of-service attacks, with which a malicious user could attempt to "steal" critical service records from your Active Directory.

However, anticipating the need for some companies to run third-party DNS servers, Windows 2000 will run with non-Microsoft DNS servers as long as those servers support Service Locator (SRV) records. If your server does not support SRV records, you need to either upgrade that server or delegate the Active Directory zones to a server that does.

Assuming that your server supports SRV records, the type of DNS server that you have will determine the level of effort required to support the Active Directory. There are two general types of DNS servers:

• Servers that support dynamic updates

• Servers that do not support dynamic updates

Servers that Support Dynamic Updates.

Dynamic DNS is described in the Request For Comments (RFC) 2136, "Dynamic Updates in the Domain Name System." BIND 8.1.2 is an example of a DNS service that supports dynamic updates. As long as all of your servers that will support the Active Directory are RFC 2136-compliant, you do not need to do anything special for Windows 2000 to work. However, you do lose the benefits of Active Directory-integrated zones and Aging and Scavenging, discussed earlier in this chapter.

Servers that Do Not Support Dynamic Updates

If your server does not support dynamic updates, as described in RFC 2136, it is highly recommended that you upgrade your server to a version of DNS that does. BIND 4.9.x and earlier versions are examples of DNS services that do not support dynamic updates. Using a server that does not support dynamic updates is strongly discouraged. However, if the upgrade is not an option, you must manually update the correct DNS zones to ensure that the Active Directory will function correctly. You will need to do the following:

• Implement a manual process for updating host records for all clients and servers.

• Implement a manual process for registering Domain controller records.

Implement a Manual Process for Updating Host Records for All Clients and Servers

It should be safe to assume that if you are using non-dynamic DNS servers in your environment today, you have an adequate manual process for adding and removing host records. Having such a process in place is extremely important, especially for the host records for your Windows 2000 Domain Controllers. The Active Directory Service Locator (SRV) records will point to those host records.

Implement a Manual Process for Registering Domain Controller Records

For every Domain Controller in your forest, you will need to manually update all of the records listed in Table 4.2.2, earlier in this chapter. To assist you, the Netlogon service creates a file on each Domain Controller that contains these records. This file is %systemroot%\config\NETLOGON.DNS.

You must be very careful to enter each of the records in the correct zones. Some of the DNS records need to be in the zone for the local Domain, whereas some of the records need to be in the zone for the forest root. Maintaining the accuracy of these zones over time is also very important. If you delete and reinstall a Domain Controller, it will be necessary to update the DNS zones (because the DSAGuid will change). Also, if you remove a Domain Controller, you must remove the appropriate records from the DNS.

Due to the features that Microsoft's DNS provides, it is the ideal choice for supporting Windows 2000. As a general rule, it is not recommended that you run a third-party DNS server to support the needs of the Active Directory. However, with a solid plan and careful implementation, it is possible to set up a reliable infrastructure without using Microsoft's DNS service.