DNS Migration Issues in a Mixed Environment

Companies have started to take a closer look at the issues related to migration from a Windows NT to a Windows 2000 (Win2K) environment. But a lot of mid- to large-size companies are operating in a mixed environment with NT, UNIX, Novell and the like, and a lot of readers I've heard from are interested in discussing the issues they'll face in a mixed environment—especially as they relate to DNS. Let's look at DNS and the migration to Win2K.

Migration Scenarios
Win2K’s trees and forests are based on the DNS naming structure. DNS is the heart and soul of Win2K and Active Directory (AD). Fortunately, most organizations already have DNS in place. When you're planning your Win2K migration, you'll need to coordinate at the highest level so that you can successfully integrate Win2K and AD in your enterprise. Let’s look at two scenarios.

In the first scenario, we'll assume that our entire organization is running an NT network and will migrate its clients to Win2K Professional (Win2K Pro). We're running DHCP, WINS (for dynamic name resolution), and DNS (for resolving Internet names). The primary DNS server resides at the corporate headquarters, and all branch offices have a secondary DNS server onsite. Furthermore, the individual offices don't connect directly to the Internet— they all go through the corporate office to get to the Internet. The corporate office will migrate first; the branch offices will follow in coming months.

In the second scenario, we'll assume that our organization runs a mixture of NT, Novell, and UNIX. Some of the departments that use Novell or UNIX have no intention of migrating to Win2K, while others will migrate in the near future. To keep things simple, we'll assume we have one location with no branch offices.

Obviously, there are several possible scenarios, and the designs will vary depending on your network architecture. I'm using these two scenarios only to give you a feel for some of the issues that you need to consider. The solutions I'll discuss might not be the best for every situation. The purpose is to make you aware of the issues, not to provide an optimal solution.

Scenario 1
In this scenario, you'll upgrade to Win2K at the corporate office by creating a new root domain. Using the company name we've registered with the InterNIC for our DNS naming structure, we name the root domain microsoft.com. Our network design specifies that our departments will each have separate Win2K domains that will serve as sub-domains of the root domain. We can name the sub-domains sales.microsoft.com, marketing.microsoft.com, and so on. All the Win2K Pro computers at the corporate office will join the microsoft.com domain. Branch office Win2K Pro clients will join their respective domains as they begin migration.

Because the branch offices won't be migrating right away, we need to decide whether to use NT 4.0 DNS servers only, a mixture of NT and Win2K DNS servers, or Win2K DNS servers only. At the corporate office, we can upgrade our DNS server to Win2K’s dynamic DNS server. All corporate office clients will dynamically register with this DNS server. At the branch offices, we have a couple of options for handling DNS and WINS.

For DNS:

• Continue to use NT 4.0 DNS servers at the branch offices and perform zone transfers with the corporate office DNS server.
• Use Win2K DNS servers only. Use Win2K’s DHCP server to dynamically register downlevel clients at branch offices with Win2K’s dynamic DNS server.

We'll use the second option because it'll simplify administration and will be a step in the right direction. When you're planning your migration, keep in mind that unlike NT DNS servers, which can only do full zone transfers, Win2K DNS servers can do either incremental or complete zone transfers.

For WINS:

• Continue to use NT 4.0 WINS servers at the branch offices and configure them for a push/pull relationship with the corporate office's WINS servers.
• Use Win2K’s DHCP server to dynamically register downlevel clients with Win2K’s dynamic DNS server, which will eliminate the need for WINS.

We'll use the second option because dynamic DNS offers us the same dynamic name resolution capabilities as WINS, plus we can use it to resolve host names on the Internet.

Scenario 2
In this scenario, you need to decide how to integrate your existing DNS structure with Win2K. Win2K implements a DNS-style naming structure based on Lightweight Directory Access Protocol (LDAP) proposals. For example, if our Win2K AD domain name is sales.microsoft.com, an LDAP name can represent it as DC=sales,DC=microsoft,DC=com,O=Internet, where DC stands for a domain component and O stands for an organization. I'd recommend that your Win2K architects be well versed in several areas, including AD, Active Directory Service Interfaces (ADSI), LDAP, dynamic DNS, and TCP/IP.

In a mixed environment, you might have to decide whether to use a contiguous or disjointed namespace for your Win2K DNS hierarchy. In a contiguous namespace, the child domains always contain the name of the parent domain in their names. For example, sales.microsoft.com is a contiguous namespace where the sales domain is a child of microsoft.com. In a disjointed namespace, the child domain doesn’t contain the name of the parent domain as part of its domain name. For example, expedia.com could be a child domain of microsoft.com, but it doesn’t contain the parent name in its name. Whether you use a contiguous or disjointed namespace determines how LDAP search operations execute. One advantage of a contiguous namespace is that a domain controller will create referrals to the child domains. In a disjointed namespace, the LDAP searches terminate because the domain controllers don't create any referrals. If you must implement a disjointed DNS namespace, there are some workarounds that require a more in-depth knowledge of AD, Schema, and LDAP.

To integrate DNS servers with non-Microsoft DNS servers (e.g., UNIX BIND servers), you should consider using only non-Microsoft servers that support dynamic updates and SRV records. BIND 8.1.2 or later servers support both dynamic updates and SRV records. Dynamic update isn't a requirement, but support for SRV record is a must. Microsoft recommends that you use BIND 8.2.1 or later, which supports dynamic updates, SRV records and, unlike BIND 8.1.2, incremental zone transfers. (For more information, refer to my columns Dynamic DNS Updates in Windows 2000 and Migrating to Windows 2000.) Microsoft recommends that you configure Win2K’s DNS server as a primary DNS server and non-Microsoft servers as secondary DNS servers in a mixed environment.

Unfortunately, I'm out of space. I'll address similar issues in future columns. If there are topics you want me to address, email me at zubair@winntmag.com.