- The Evolution of Directory Services
- Understanding the Development of AD DS
- AD DS Structure
- Outlining AD DS Components
- Understanding Domain Trusts
- Defining Organizational Units
- Outlining the Role of Groups in an AD DS Environment
- Understanding AD DS Replication
- Outlining the Role of DNS in AD DS
- Outlining AD DS Security
- Getting Familiar with AD DS Features in Windows Server 2016
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Outlining the Role of DNS in AD DS
When Microsoft began development on AD DS, full compatibility with the domain name system (DNS) was a critical priority. AD DS was built from the ground up, not just to be fully compatible with DNS but also 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, AD DS can expand on 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, AD DS 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 later.
Given the importance of DNS in Windows Server 2016 AD DS, a thorough understanding of DNS is a must. Chapter 9, “Domain Name System, WINS, and DNSSLC,” discusses DNS in Windows Server 2016 in detail.
Examining DNS Namespace Concepts
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 AD DS can be published on the Internet, such as microsoft.com or cco.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.
External (published) namespaces—A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace was previously common for organizations that wanted the full convenience of having their commonly used Internet domain name represent their AD DS structure. Best practices have evolved to make this model less attractive, however, as security becomes a concern and DNS must be set up as “split brain” because it is generally ill-advised to have internal AD DNS zones accessible from the Internet.
Internal (hidden) namespaces—For many organizations, publication of their internal domain structure is too high a security risk. These organizations can easily define their AD DS with an internal namespace that is not readable from the Internet. For example, a company might have an external DNS namespace of cco.com but decide that its AD DS structure will correspond to cco.internal 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 ilovemydomain.verymuch if you want (although it’s not recommended, of course). For practical reasons, however, the .internal namespace has been specifically reserved for private name addressing, and using it is a best practice approach in many cases.
Dynamic DNS
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 Server 2016 automatically updates the DNS table based on registrations, and can work in conjunction with Dynamic Host Configuration Protocol (DHCP) to automatically process DNS changes as clients are added and removed from the network infrastructure. DDNS is not required for AD DS to function properly, but it makes administration much easier than previous manual methods.
Comparing Standard DNS Zones and AD-Integrated DNS Zones
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 Server 2016.
AD DS expands on other implementations of DNS by allowing administrators to integrate DNS into AD DS. By doing this, the DNS zones themselves exist as objects in the AD DS, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off AD DS traffic, and the DNS records are stored as objects in the directory. In the Windows Server 2016 implementation of AD DS, AD-integrated DNS zones are optimized by being stored in the application partition, thus reducing replication traffic and improving performance. For more information about DNS, see Chapter 9.
How AD DS DNS Works with Foreign DNS
Often, some local administrators might be hesitant to deploy AD DS because of their desire to maintain their own foreign DNS implementation, usually UNIX BIND. If this is the case, it is possible for Windows Server 2016 DNS to coexist in this type of environment, as long as the DNS supports dynamic updates and SRV records (BIND 8.2.x or later). 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 Server 2016 to coexist peacefully in these types of environments is, therefore, key.