The Active Directory and Dynamic DNS

DNS, or the Domain Name System, is the most widely used network address/ name translation service in the world, and is used on the Internet. This service was created many years ago when the first DARPA network, the predecessor of today's Internet, experienced rapid growing pains and needed a distributed naming service that could be used to locate the address of any server in the network.

You can read more about the Domain Name System (DNS) in Chapter 30, "Network Name Resolution."

The Internet has grown so large in the past years that, without a distributed naming service, it would be almost impossible to keep track of all nodes in the network, much less the services they offer. DNS has evolved to contain many types of records that can be used to translate names to addresses. These include not only names of servers or workstations on the Net, but also services, such as the World Wide Web and email.

Dynamic DNS

Administering a large number of computers in a network can be quite a chore. Moving a computer from one network subnet to another used to require that the administrator manually reconfigure the DNS servers in the enterprise so that he or she could accurately translate the computer's name to its correct address. With the advent of mobile computing and the proliferation of laptops that are here today, gone tomorrow, reconfiguring network addresses can become a full-time job on a large network.

The Dynamic Host Configuration Protocol (DHCP) solves part of this problem by allowing a computer to request a network address, along with other configuration information, when it boots into the network. However, this doesn't completely solve the problems that arise as the result of mobile computing. After the client computer has obtained network address and configuration information, how does it communicate that information to other computers so that they can locate it on the network?

You can read more about DHCP in Chapter 29, "BOOTP and Dynamic Host Configuration Protocol (DHCP)."

In early versions of Windows NT, the Windows Internet Naming Service (WINS) was the answer to this problem. After a computer boots, it can contact a WINS server, which acts very much like a dynamic DNS server. It accepts registrations from clients and stores or updates their information so that other computers can query the database to find the client's network address.

In Windows 2000/Server 2003, you still can use the WINS service, which might be helpful for legacy Windows clients if you have a mixed network of Windows 2000 and earlier Windows NT computers. However, Windows 2000 and Windows Server 2003 come with an updated version of Microsoft's DNS, which includes the capability to dynamically update the DNS database. In fact, using DNS is the method that clients in an all Windows 2000/Server 2003 network use to locate domain controllers in the network.

Note

Dynamic updates to the DNS database are defined in RFC 2136. This RFC defines the UPDATE opcode and a format to be used as the update message, along with procedures that can be used to implement dynamic DNS. Dynamic DNS has been gaining acceptance with vendors of other operating systems. Thus, you might be able to use a DNS server from another operating system within your Windows network.

How the Active Directory Uses DNS

The Active Directory uses DNS to keep track of domain controllers. DNS is used as a locator service as well as a name/address translation service. Remember that the Active Directory provides a service to its users through the LDAP protocol. Services can be recorded in DNS through Service Resource Records (SRV RRs), and this is how the Active Directory uses DNS.

Note

SRV Service Resource Records are defined by RFC 2052, "A DNS RR for Specifying the Location of Services (DNS SRV)," by Gulbrandsen and Vixie.

An SRV RR record consists of data in this format:

  service name.protocol.domain  

Because the Active Directory uses LDAP, a resource record for this service would look like this:

 LDAP.TCP.twoinc.com 

Because the DNS that is provided with Windows is a dynamic DNS, there is no associated administrative work when you add domain controllers to your network. Each domain controller automatically contacts a DNS server and provides it with the necessary information to register its name, its address, and the services it offers. Each domain controller also checks back at frequent intervals to be sure that the information is accurate and will make changes to the DNS information as changes are made on the server.

One thing to note about the use of DNS as a locator service is that you do not have to use Microsoft's own DNS server to have an Active Directory “enabled network. The DNS product you use, however, must support SRV records, because this is how domain controllers advertise themselves to the network. The DNS server you use does not have to use dynamic DNS functions, however. This just makes the DNS administrator's life a lot easier in a rapidly changing environment.

Using Sites to Manage Large Enterprises

In Windows 2000/2003 a site is nothing more than a collection of well-connected computers that exist on an IP subnet, and that usually are located close to each other geographically . The grouping of computers into sites is done to make replication fast and efficient. It is not a concept that relates to managing or administering users, resources, or network security. The following are two important things to remember about a site, as used by Windows:

• A domain can have computers in more than one site.

• A site can contain computers from more than one domain.

Windows 2000/2003 uses only domain controllers to hold the Active Directory database. There is no longer a primary domain controller that controls writing or modifying directory information and backup domain controllers that provide a read-only service to users and computers . In Windows, all domain controllers can receive updates to the database, and the changes then are replicated to all other domain controllers that participate in the directory tree.

The Knowledge Consistency Checker service is run on every domain controller, and it is this service that establishes connections with other domain controllers within the site to be sure that directory replication can occur. Although the administrator can configure connections manually, the consistency checker will automatically establish new connections when it determines that there is a hole in the replication topology within a site.

The administrative tool that is used to control how servers participate in directory replication is the Active Directory Sites and Services Manager. This MMC snap-in allows you to

• Add new sites and subnets and associate a site name with a subnet

• Show all the sites that exist throughout the enterprise

• Show all the servers that are contained in each site

• Create and display the links between servers and the links between sites, including the protocols that are used for replication

• Show the timing values used to schedule replication

• Manage subnets

Note

Sites are represented in the Active Directory database and are defined by the site object. Although all computers in the directory have a computer object, domain controllers also have a server object. This server object is a child object of the site object that represents the site to which the domain controller is assigned.

Directory Replication

LDAP v3.0 is the current LDAP Internet standard. For the Windows implementation of directory services, Microsoft uses a proprietary method called multimaster replication, because there is not yet a standard method for replication between LDAP directory servers. However, RFC 3384 is an informational RFC that does specify requirements for replication of LDAP information. Time will tell whether an Internet standard is developed, and whether Microsoft adopts it.

In Windows NT, primary domain controllers (PDCs) were responsible for updates to the directory database (the old SAM). Additions or modifications to the database were made on the PDC and at regular intervals replicated to backup domain controllers throughout the network. The most obvious disadvantage this system has is that without a PDC, no changes can be made to the database. When a PDC becomes unavailable, because of its own failure or possible network link failure, users still can log on because they can be authenticated by a BDC. However, if you have a large enterprise, perhaps a global one, it is almost necessary to have a PDC at every geographical site where frequent changes occur, or to have an extremely good network infrastructure.

Using the Active Directory, any domain controller can receive updates or additions to the Active Directory database. These changes are propagated to other domain controllers based on update sequence numbers (USNs) . The USN is a 64-bit number used by the Active Directory to determine which updates are the most recent. In addition to the server's USN, each property (or attribute) in the database has its own property version number. These two numbers are used by multimaster replication to ensure that updates are correctly applied throughout the enterprise.

Because all replicas of the directory database can be written to, it is possible that a change can be made before a previous change has been fully replicated throughout the enterprise. Some directory databases use timestamps to determine which update is the most recent. This method requires that every server be tightly synchronized with all other servers with respect to the correct time. Windows 2000 does provide a time service that can be used to synchronize servers, but with one exception: The timestamp is not the method used to determine which is the correct update to apply to a directory update message.

Each server in a network has its own USN, which it advances when it makes an update to the directory. Each server also stores a table of USNs ”the highest USN it has received during previous replications from each server in the network. When replication starts, a server requests from other servers only those changes that have a higher USN than the one it has stored for each server during previous replication sessions. This minimizes the amount of information that needs to be exchanged between servers during the replication procedure. Because each server knows exactly which changes it has received from every other server in the network, replication between servers is efficient.

This method also allows a server to recover quickly when it crashes or some other failure, such as a network failure, occurs. All it must do is request updates that are greater than the USN it has stored for the other servers in the network. This means that a full replication between servers is not necessary in the event of a catastrophe.

Property version numbers come into play when a specific attribute is modified on more than one replica of the database within a short period, before the replication service can update the change on all nodes. Remember that with the Active Directory's distributed nature, each domain controller holds a writable copy of the directory database. A property version number is incremented only on the server on which the change is actually made. It is not incremented on a server that is receiving it as an update.

The only time a timestamp is used during multimaster replication is when a collision occurs. This happens when a server receives an update message from another server, and although the property version numbers are the same, the contents of the attribute are not. In this case, and only in this case, the timestamp on the update is used. If the update message has a timestamp later than the value stored with the property, the update is applied to the data; otherwise , it is discarded.

Summarizing the Directory Data Using the Global Catalog

The Active Directory is scalable to millions of objects. The directory is partitioned into domains, because it would be very difficult to store a complete copy of the entire directory database on a single server. Of course, with the advances being made in CPU speed and storage capabilities, this might be possible in the future, but for now it is not practical.

One of the assumptions behind the partitioning of the directory is the fact that most queries that are made to the directory are for local information. Users generally want to locate a printer or another resource that is near them. Occasionally, it might be desirable to locate a printer that resides in a different geographical location, but for the most part, queries are for local resources.

To satisfy a query for information that cannot be found in the local portion of the Active Directory, it is necessary to query every other partition of the directory until the information is found. This too can be an impractical method. In a large enterprise, moderate use of this type of query, whereby the entire database is searched, could cause significant network and CPU resource consumption.

The global catalog is the answer that Microsoft has implemented to solve this problem. The global catalog is a subset of the entire directory. It holds entries for every object that exists in all partitions of the directory, but it contains only selected attributes for each object. If your query cannot be satisfied by querying the global catalog, the query will have to be resolved by searching a portion of, or possibly the entire, directory database.