Active Directory is tightly coupled with the Domain Name System (DNS). Both clients and domain controllers use DNS to locate domain controllers in a particular site or that serve a particular function. Each domain controller requires numerous resource records to be present in DNS so it can advertise its services as a domain controller, global catalog server, PDC Emulator, etc. For a detailed description of each of these records plus much more on DNS, see Chapter 6 in Active Directory, Second Edition (O'Reilly).
One of the innovative uses of Active Directory is as a store of DNS data. Instead of using the antiquated primary and secondary zone transfer method or even the more recent NOTIFY method (RFC 1996) to replicate zone data between servers, AD-integrated zones store the zone data in Active Directory and use the same replication process used to replicate other data between domain controllers. The one catch with AD-integrated zones is that the DNS server must also be a domain controller. Overloading DNS server responsibilities on your domain controllers may not be something you want to do if you plan on supporting a large volume of DNS requests.
The only time DNS data is stored in Active Directory is if you have a zone that is AD-integrated. When using standard primary and secondary zones that are not AD-integrated, the DNS data is stored locally in the file system of each DNS server in zone files. If you have an AD-integrated zone under Windows 2000, a container is created in the following location: cn=<ZoneName>,cn=MicrosoftDNS,cn=System,<DomainDN>, where <ZoneName> is the name of the zone. For Windows Server 2003, you can use application partitions to store DNS data in an alternate location. By default, there are three options:
Store DNS data on all domain controllers in a domain (only option for Windows 2000).
Store DNS data on all domain controllers that are DNS servers in the domain.
Store DNS data on all domain controllers that are DNS servers in the forest.
The default location for the second option is dc=DomainDNSZones,<DomainDN> and for the third option, it is dc=ForestDNSZones,<ForestDN>. These two locations are actually application partitions that are replicated only to the domain controllers that are DNS servers in the domain or forest, respectively.
Inside the MicrosoftDNS container, is a dnsZone object for each AD-integrated zone. Inside of the dnsZone container are dnsNode objects, which stores all resource records associated with a particular node. In the following textual representation of an A record, the dc1.rallencorp.com name is considered a node (generally the left side of the resource record).
dc1.rallencorp.com. 600 IN A 6.10.57.21
There could be multiple resource records associated with the dc1.rallencorp.com name, so Microsoft decided to implement each distinct name as a dnsNode object. The dnsNode object has a dnsRecord attribute, which is multivalued and contains all of the resource records associated with that node. Unfortunately, the contents of that attribute are stored in a binary format and are not directly readable.
Table 13-1 and Table 13-2 contain some of the interesting attributes that are available on dnsZone and dnsNode objects, respectively.
Attribute |
Description |
---|---|
dc |
Relative distinguished name of the zone. |
dnsProperty |
Binary formatted string that stores configuration information about the zone. |
msDS-Approx-Immed-Subordinates |
Approximate number of nodes contained within the zone. This is new to Windows Server 2003. |
Attribute |
Description |
---|---|
dc |
Relative distinguished name of the node. |
dnsRecord |
Binary formatted multivalued attribute that stores the resource records associated with the node. |
dnsTombstoned |
Boolean that indicates whether the node is marked for deletion. FALSE means it is not and TRUE means that it is. |