January 27, 2001, 12:53 PM — Active Directory (AD) is arguably the most crucial new feature in Windows 2000, so it's important to devise a plan that ensures a smooth rollout for it. One of the first steps in planning your AD deployment is to work out your domain name system (DNS) integration strategy. Successful DNS integration is a critical factor in AD deployment, because the directory relies on DNS as a location service. This means that DNS helps clients find Windows 2000 domain controllers and other AD-related services for a particular domain.
Since DNS integration is so vital, and since so many issues depend on choosing the right DNS integration strategy -- particularly when working with an existing Unix-based DNS environment -- I'll dedicate the next few columns to the topic.
This time around, I'll provide an overview of AD's DNS requirements and describe the three options for implementing an AD/DNS strategy. In future columns I'll cover a few deployment options and approaches that should help you plan your own AD/DNS integration strategy, whether you plan to deploy the Microsoft DNS service that ships with Windows 2000, or another DNS server, such as a Unix-based implementation.
What DNS brings to the party
If you've done any reading on the subject, you may already be familiar with AD's DNS requirements. For those of you who are just getting started, let me take a moment to cover them.
AD's primary DNS requirement is support for DNS service (SRV) resource records. The directory uses these to advertise the availability of services to AD-aware clients. From a DNS perspective, SRV records are used to map a particular service and its TCP/IP port number to a particular host that offers or advertises that service.
In addition to SRV records, support for dynamic DNS (DDNS), which allows for client self-registration of DNS records, is also required by AD in order to support dynamic registration of AD services. Although you could technically get by without DDNS, having to manually register AD's SRV records with DNS is enough of an inconvenience and provides enough room for error that DDNS is the only realistic solution. So you can consider DDNS a virtual requirement.
Let me elaborate on this point for a moment to help illustrate how AD uses DNS. In order for AD-aware clients to locate AD domain controllers and other AD-related services, each AD domain controller registers these services in DNS. Among the services registered are the TCP/IP ports for the LDAP and Kerberos services for a Windows 2000 domain controller. In addition, AD sites, domain controllers within each site, and AD Global Catalog servers are also registered in DNS. Sites are administrator-configurable constructs that define areas of high bandwidth for efficient authentication and directory replication.
For each service an AD domain controller advertises, the DNS record data contains the service's TCP/IP port and the name of the corresponding host that has advertised the service. Let's analyze the following example DNS SRV resource record:
_ldap._tcp.itworld.com. 600 SRV 0 100 389 win2kdc.itworld.com.
This particular SRV record advertises the LDAP service for the domain controller win2kdc in the AD domain itworld.com. Each SRV resource record is registered in the form _Service._Protocol.DNSDomainName. In the example above, this is represented in the first portion of the record, which identifies the LDAP service as protocol type TCP for the DNS domain itworld.com. The value 600 is the record's TTL (time to live) in seconds -- 10 minutes, in this case. SRV is the record type, identifying the record as a service resource record. The three numbers that follow, 0, 100, and 389, are the record's DNS priority, DNS weight, and the service's port number. Last comes the name of the host advertising the service. The NETLOGON service for each AD domain controller is responsible for registering SRV resource records -- of which there are roughly 20 per domain controller -- with DNS.
