So far, this series on AD/DNS strategies has covered migrating a Unix-based DNS environment to Windows 2000 and using your Unix-based DNS to support Active Directory. But now my columns will start heating up, because I'll be discussing the strategy of integrating Unix and Windows 2000 DNS systems -- that is, running both Unix-based and Windows-2000-based DNS servers in the same environment. In this approach, you leave your Unix-based DNS servers in place to manage your primary DNS domain (in our example, itworld.com) and designate a subdomain (such as win2k.itworld.com) to be hosted on Windows 2000 DNS servers for the purpose of supporting AD.
This practice is often referred to as delegation because it effectively distributes authority for a portion of DNS namespace to another name server. In my next few columns, I'll be discussing some of the issues and challenges of delegation, as well as identifying potential solutions. In this column, I'll start with an overview of the main issues and a quick technical discussion of how to delegate a new DNS domain.
After evaluating other options, delegating a DNS domain for AD use may seem like a simple, logical approach to solving the AD/DNS integration problem. In fact, if AD/DNS integration has come up in conversation or in other articles you've read, you've probably already encountered a common approach: Create a new DNS child domain under your main domain and delegate it to Windows-2000-based DNS name servers. Unix people maintain their hold on the core DNS domain and you get to run AD on a Windows 2000-based system. It's a win-win situation, right?
We'll spend much more time and thought on that issue because, as with most things in this business, the simple answer is insufficient. The delegated-DNS-domain approach may, in fact, be a win-win situation from a political perspective. However, depending on your environment, it can be far more complicated to plan and implement than other AD/DNS scenarios. Consequently, depending on the size of your organization, this approach may be anything but simple.
Key planning factors
Delegating a DNS zone to AD can be a more complex undertaking than it initially sounds because of several issues, including:
- Determining an adequate IP/DNS management model
- Determining which set of DNS name servers clients should resolve against
- Planning for efficiency in forward lookups across a distributed environment -- from the parent domain to the child domain and vice versa
- Implementing recursion vs. iteration
- Settling reverse lookup
- Visibility across the DNS namespace
In smaller environments -- either those with closely distributed or relatively few DNS name servers -- these issues are not of great concern. However, in large, distributed environments with many name servers, you should give these planning factors careful consideration in order to build an infrastructure that is efficient, resilient, and bandwidth-sensitive. The first step is acknowledging these issues up front so you can plan around them.
For starters, you will need to hack out an IP/DNS management model. This issure raises several questions, such as: When you bring up a new DNS subdomain, will you also migrate client host records to it? In addition, will you migrate Windows 2000 desktop client settings so clients use your new Windows 2000 servers as their DNS name servers (both primary and secondary)? If so, how will these decisions change the management of IP addresses and DNS-record entry in your organization? You will definitely want to resolve these issues quickly, so you can either make adequate support arrangements with other departments or devise coping strategies for the new management tasks you stand to inherit.
Once you have a handle on organizational issues, you can focus on the technical elements of AD/DNS integration. Whether you decide to migrate host records to your AD-delegated subdomain or point clients to resolve against your Windows 2000 name servers, you should understand completely the details of DNS delegation. That will help you plan for the most efficient DNS infrastructure with respect to forward and reverse DNS lookups. That said, let's get into the details.
Delegating a DNS subdomain is a relatively simple configuration exercise. It consists merely of adding a few records to the zone database file on the master name server from which you will be delegating the new zone.
In my example, I will delegate the zone win2k.itworld.com to my Windows 2000 name servers from the itworld.com domain, which is hosted on my Unix name server. On my Unix server, I will need to add name server (NS) records to the itworld.com zone file. Those records will tell requesters of host lookups in the win2k.itworld.com domain to contact the Windows-2000-based name servers to resolve their query.
If I have five Windows 2000 name servers, I will need to add five NS records to my zone file as follows:
<font face="Courier"> wink2k IN NS ns1.win2k.itworld.com.<br> <br> wink2k IN NS ns2.win2k.itworld.com.<br> <br> wink2k IN NS ns3.win2k.itworld.com.<br> <br> wink2k IN NS ns4.win2k.itworld.com.<br> <br> wink2k IN NS ns5.win2k.itworld.com.<br> </font>
Since those NS records reference host names rather than IP addresses, I will need to add host records for each of the five name servers so other servers (and clients) will know how to reach these name servers to resolve their queries. Often referred to as "glue," those host records are the adhesive between the parent domain and the subdomain. In my example, I would add the following five host records:
<font face="Courier"> ns1.win2k.itworld.com. IN A 192.168.1.10<br> <br> ns2.win2k.itworld.com. IN A 192.168.2.10<br> <br> ns3.win2k.itworld.com. IN A 192.168.3.10<br> <br> ns4.win2k.itworld.com. IN A 192.168.4.10<br> <br> ns5.win2k.itworld.com. IN A 192.168.5.10<br> </font>
Notice that in my example, each host resides on a different IP subnet. This represents distributed placement of those name servers, as would be the case in a distributed environment.
You will also need to add PTR records to each host's corresponding reverse-lookup zone. For now, let's assume that we will leave these reverse-lookup zones on the Unix-based name servers. (I'll discuss the merits of hosting these on Windows 2000 in a future column.)
Next, you will need to set up your new zone, win2k.itworld.com, on your first Windows 2000-based name servers. You can do this from Windows 2000's DNS management console. After setting up that zone, you should then configure your Windows 2000 name server to use your Unix servers as DNS forwarders. This simply instructs the server to query your Unix servers if it is not familiar with the DNS record for which a client is asking. In short, it will allow forward lookups from the Windows 2000.itworld.com domain to the itworld.com domain. For optimal response times and network efficiency, you should indicate as forwarders the Unix servers that are closest to your Windows 2000 server in terms of network cost. For redundancy's sake, you should specify at least two or more forwarders.
After completing these steps, your basic configuration will be done. To ensure that everything is working properly, you can test your configuration, using the
<font face="Courier">nslookup</font>tool to perform queries against name servers in both DNS zones: itworld.com and win2k.itworld.com. Then you can continue to configure your additional name servers for the win2k.itworld.com domain.
This setup will give you a basic configuration to work from, but we haven't really delved into the ins and outs of forward- and reverse-lookup options. In my next column I'll analyze forward-lookup options and address ways to ensure the best efficiency for forward lookups across your newly modified DNS environment.
Windows on the Enterprise is a biweekly column that focuses on Windows 2000 technologies, as well as deployment and support strategies for enterprise environments.