- Evolution of Directory Services
- Active Directory Development
- Active Directory Structure
- Active Directory Components
- Domain Trusts
- Organizational Units
- Groups in an Active Directory Environment
- Active Directory Replication
- DNS in Active Directory
- Active Directory Security
- Active Directory Changes in Windows .NET Server 2003
- Best Practices
DNS in Active Directory
When Microsoft began development on Active Directory, full compatibility with the domain name system (DNS) was a critical priority. Active Directory was built from the ground up not just to be fully compatible with DNS but to be so integrated with it that one cannot exist without the other. Microsoft's direction in this case did not just happen by chance, but because of the central role that DNS plays in Internet name resolution and Microsoft's desire to make its product lines embrace the Internet.
While fully conforming to the standards established for DNS, Active Directory can expand upon the standard feature set of DNS and offer some new capabilities such as AD-Integrated DNS, which greatly eases the administration required for DNS environments. In addition, Active Directory can easily adapt to exist in a foreign DNS environment, such as Unix BIND, as long as the BIND version is 8.2.x or higher.
Given the importance of DNS in Windows .NET Server 2003's Active Directory, a thorough understanding of DNS is a must. Chapter 9, "Domain Name System," goes into greater detail on DNS in Windows .NET Server 2003.
A DNS namespace, simply defined, is the bounded logical area formed by a DNS name and its subdomains. For example, europe.companyabc.com, asia.companyabc.com, and companyabc.com are all part of the same contiguous DNS namespace. A DNS namespace in Active Directory can be published on the Internet, such as microsoft.com or msn.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.
External (Published) Namespace
A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace is common for organizations that want the full convenience of having their commonly used Internet domain name represent their Active Directory structure. While security becomes a larger issue for published Active Directory namespaces, the convenience of being able to access servers directly from the Internet makes this option a popular one for organizations. For example, an Exchange server running Outlook Web Access could be set up as mail.companyname.com and easily accessible from anywhere in the world. Users would more readily understand how to connect, and in these cases their e-mail addresses would likely be firstname.lastname@example.org. This will not be the first time that the balancing act between greater security and convenience will arise during the design of a Windows .NET Server 2003 deployment.
Internal (Hidden) Namespace
For many organizations, publication of their internal domain structure is too high a security risk, despite the advantages. These organizations can easily define their Active Directory with an internal namespace that is not readable from the Internet. For example, a company may have an external DNS namespace of cco.com but decide that its Active Directory structure will correspond to internal.cco or any namespace it wants. Bear in mind that any combination will work for internal namespaces because there is no limitation on using .com, .net, .gov, and so on when dealing with a namespace that is not published. For all intents and purposes, you could name your domain cucamonga.funkychicken if you want.
If you decide to use a domain namespace that theoretically could be bought and used on the Internet either now or in the future, it is wise to purchase the rights to that domain name to prevent potential conflicts with name resolution in the future. For example, if you choose the internal namespace companyabc.com, you may want to first verify that it is not taken and buy it if you can. If you find the domain name is already owned by another company, you may choose a different domain name for your Active Directory namespace. Even though your domain might not be published on the Internet, home or laptop users who need dial-in or VPN access to your domain may experience conflicts because they would be incorrectly routed to the wrong DNS name on the Internet instead of your company's namespace.
Dynamic DNS (DDNS) was developed as an answer to the problem of DNS tables having to be manually updated when changes were made. DDNS in Windows .NET Server 2003 automatically updates the DNS table based on registrations, and can work in conjunction with DHCP to automatically process DNS changes as clients are added and removed from the network infrastructure. DDNS is not required for Active Directory to function properly, but it makes administration much easier than previous manual methods.
While DDNS is fully supported by Windows .NET Server 2003 and is typically enabled for all Windows Active Directory domain-to-domain name replication, DDNS is not commonly implemented at the enterprise level. Organizations with Unix-based DNS servers tend to manually or statically update DNS tables rather than dynamically update DNS tables. This is solely the choice of the DNS administrator in an organization to enable DDNS from Active Directory DNS to the enterprise DNS.
Standard DNS Zones Versus AD-Integrated DNS Zones
A Windows .NET Server 2003 that is not a domain controller uses standard DNS by default. Standard DNS essentially stores all name records in a text file and keeps it updated via dynamic updates. If you are accustomed to using Unix BIND DNS or other standard forms of DNS, this is essentially what Standard DNS is in Windows .NET Server 2003.
Active Directory expands upon other implementations of DNS by allowing administrators to integrate DNS into Active Directory. By doing this, the DNS zones themselves exist as objects in the Active Directory, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off Active Directory traffic, and the DNS records are stored as objects in the directory. In Windows .NET Server 2003's implementation of Active Directory, AD-integrated DNS zones are optimized by being stored in the application partition, thus reducing replication traffic and improving performance. For more information on DNS, see Chapter 9.
AD DNS in Co-existence with Foreign DNS
Often, some local administrators may be hesitant to deploy Active Directory because of their desire to maintain their own foreign DNS implementation, usually Unix BIND. If this is the case, it is possible for Windows 2000 DNS to co-exist in this type of environment, as long as the DNS supports dynamic updates and SRV records (BIND 8.2.x or higher). These situations occur more often than not, as political situations within IT departments are often divided into pro-Microsoft and pro-Unix groups, each of which has its own ideology and plans. The ability of Windows .NET Server 2003 to co-exist peacefully in these types of environments is therefore key.
For a more detailed analysis of DNS in Windows .NET Server 2003, see Chapter 9.