In-Depth

Team Effort: Integrating Windows 2000 DNS with Unix DNS

Microsoft's new domain name service is enticing but requires significant planning, especially across platforms and operating systems. Perhaps the greatest challenge is interoperability with Unix DNS.

• By Kevin Kocis
• 05/01/2000

As companies begin to integrate Microsoft’s new operating system with their current Windows NT environments, big obstacles will begin to surface for enterprise IT teams. One of those is the interoperability and integration of Windows 2000’s Active Directory into their directory service infrastructures. Active Directory is Microsoft’s directory services debut. One of the company’s goals for AD is to consolidate directory services through interoperation with other directories. My focus here will be on Windows 2000 and Unix Domain Name System (DNS) interoperability, which can provide a sturdy framework from which to begin to build your AD implementation.

DNS Interoperability

Great challenges and significant planning go into designing an effective directory service. Perhaps the greatest of these challenges in the enterprise is interoperability. Since most enterprises currently host DNS on Unix servers running BIND (which I’ll explore shortly), how do they integrate AD, which relies entirely on DNS, into this environment?

Since clients in a Win2K environment look up SRV resource records in the DNS server to locate their network’s AD and services, it’s important that Unix servers have recent BIND versions installed to perform these functions.

Some of the new DNS requirements of AD are:

• Support of SRV records (RFC 2782).
• Recommended support of dynamic updates (RFC 2136).
• Recommended support of incremental zone transfer (IXFR) (RFC 1995).
• BIND 8.2.2 or higher will support DNS extensions used by AD.

Win2K clients use DNS for name resolution and for locating domain controllers for logon. Down-level clients (Windows NT 4.0 and earlier and Windows 9x) rely on NetBIOS, which uses WINS, broadcast or LMHOSTS files. WINS is used for domain controller location. Since Win2K DNS is WINS-“aware,” a combination of DNS and WINS can be implemented in a mixed environment. NT 4.0 clients can register in Win2K WINS, and Win2K clients can register in NT 4.0 WINS.

In the Real World

In the real world, many companies running heterogeneous environments maintain DNS domains on Unix servers. There are a number of reasons for this. Most large companies—as well as the World Wide Web—initiated DNS domains on Unix servers. Microsoft didn’t enter the DNS arena until the release of NT 4.0 in 1996. Today, most of the Internet’s primary DNS servers run Unix BIND (Berkeley Internet Name Domain), which is shipped free with most Unix systems. BIND is well understood and stable. Due to shortcomings in Microsoft’s previous release of DNS, companies continue to maintain Unix-based implementations and third-party solutions.

Interoperability Issues

If you get anything out of this article, it should be this: It’s imperative that you coordinate and plan your AD and Unix DNS integration with your current DNS team. While AD may sound quite enticing to the Windows support team of a larger company, if you’re operating in a heterogeneous environment, the debate over directory services may turn into nothing short of a technology holy war.

Many large enterprises have been hosting their DNS domains on Unix servers for a long time. From their perspective, why change something that isn’t broken, especially for an unproven and proprietary Microsoft product? Windows DNS has raised the stakes by being fully compliant with Internet standards and by providing a wider spectrum of features than specified in the current RFC documents. Because of its advanced features, you need to be cautious when planning integration, particularly AD-integrated zones.

When integrating AD into an existing DNS infrastructure, your discussions should focus on whether the AD namespace will join, overlap, or trump your existing DNS namespace. If you’re in a larger company, chances are the AD service you’re designing will need to be integrated into existing DNS infrastructure. Let’s explore in greater detail the three options for integrating Win2K DNS into your current DNS:

• Implement Microsoft DNS in AD and replace current DNS services.
• Integrate your Unix DNS structure into the DNS required for Win2K.
• Maintain your Unix DNS structure with Win2K.

Your choice will depend on a variety of variables, including your current DNS infrastructure and specifications, as well as the many pending political issues.

Microsoft’s Choice

Option one (see Figure 1), implementing proprietary Microsoft DNS with AD, is Microsoft’s choice for obvious reasons. If your company is committed to redesigning your DNS infrastructure around Win2K AD, this should be your choice. If you have older Unix machines running older versions of BIND (such as 4.x) and feel the upgrade process isn’t worthwhile based on the enterprise shift to AD, consider this option. Migration from NT 4.0 DNS is relatively easy.

Figure 1. Option 1 for DNS integration involves: 1) bringing in Microsoft DNS as a secondary zone; 2) performing a zone transfer; 3) removing Unix DNS services; 4) last, optionally switching to AD integrated zones.

When migrating Unix DNS servers to the Win2K DNS, you should first introduce Win2K DNS servers as secondary servers. Configure a zone transfer from a master to a secondary Win2K DNS server and make sure there are no errors in the zone transfer process. You may receive errors if the Win2K DNS server can’t recognize records sent by the Unix DNS server during the zone transfer. You should either repair or remove the records from the zone in order for the zone transfer to complete successfully. You can also FTP the forward and reverse zone files from your Unix DNS server (db.xxx files located in etc/named.boot or etc/named.conf depending on the BIND version) to the C:\winnt\system32\dns directory on your Win2K DNS server.

After you’ve successfully completed this task, your secondary zones can be upgraded to DNS integrated zones. You should change the State of Authority (SOA) resource record to one of the AD-integrated DNS servers. Then you can terminate your Unix DNS servers (to avoid duplicate SOA records for the same zone) and remove them from the network.

As I mentioned earlier, Microsoft DNS meets and exceeds all Internet DNS server requirements. Microsoft DNS also supports Unicode and full DHCP integration and provides a friendly graphical interface. Standardization is a key to maintaining total cost of ownership and provides a focal point for support (in other words, a less diverse support environment). Another advantage is that conventional zone transfers become obsolete in the presence of AD’s multiple-master replication scheme.

The disadvantage will come in the form of integration. One issue is that AD-integrated zones must be stored on DCs in the same domain. If you need to cross domains, then you must create secondary zones at other DNS servers outside the domain.

Implementing Microsoft DNS in a Unix DNS environment will require additional efforts, including the transferring of resource records. It’s imperative that you work closely with your current DNS administrators regardless of which option you choose. Another caveat to integrating DNS in AD is that if the directory is unavailable—you guessed it—so is DNS. This is a catch-22, since DCs in other domains need DNS to find AD services; if DNS is unavailable, you may experience difficulty reaching the DCs to repair them. As with any DNS implementation, I recommend maintaining a conventional or standard secondary zone; in the event of an emergency, you can grab the necessary zone file and rebuild as necessary.

Integrate Current DNS Structure

Option two (see Figure 2) is to integrate your current DNS structure into the DNS required for Win2K. If your current DNS meets the recommended requirements for Win2K (RFC 2782, SRV records; RFC 2136, dynamic updates; and RFC 1995, incremental zone transfer) and you’ve tested dynamic updates, you can integrate it with Win2K AD. This includes BIND 8.2.2 and higher, as well as Novell’s NetWare 5.0. Remember that BIND 4.9.6 and 4.9.7 meet the minimum requirements. However, BIND 8.x supports dynamic updates, and I would strongly recommend updating to this version before integrating with AD.

Figure 2. In option 2, not an optimal approach, you implement Microsoft DNS as a corporate domain root and maintain Unix DNS as a subdomain. This isn't an optimal approach if you're running an AD-compatible version of BIND (version 8.2 or later).

Do note, however, that you would want to test this thoroughly to verify the impact on your current DNS, WINS, as well as DHCP integration. If your Unix servers are running an earlier version than BIND 8.2.2, I recommend updating to interact with the enhanced features of AD, at the time of this writing there are no migration or upgrade tools available. The different versions of BIND have separate directories and different file nomenclature, so you’re essentially involved in a not-so-glamorous copy and paste job.

Integrating your current DNS structure into Win2K DNS requires less administrative effort to implement than straight Win2K DNS. Your company can maintain current equipment and infrastructure. Unix and NT administrators can cohabitate. And you can focus on your Win2K implementation rather than fighting a DNS war.

There are some disadvantages, of course. Many Unix DNS servers are running BIND 4.x, and this may create a crossroads situation, upgrade or convert. Also an issue: the possible increase in future administrative overhead and manual data entry. There will also be a single point of failure for dynamic registrations.

Enterprises currently running Unix DNS at the root level will challenge the “demotion” to a subdomain at Microsoft’s suggestion. Despite maintaining Unix equipment as a budget plus, the process of moving a stable, existing DNS infrastructure to a subdomain will not be viewed as a value-added component of integration. As a result, many organizations running later versions of BIND will elect option 3.

Don’t Fix What Isn’t Broken

Option three (see Figure 3) is to supplement your current DNS structure with Win2K. If your company hasn’t installed and maintained recent BIND versions on your root DNS servers and issues have been minimal, you may decide that there’s no reason to “fix something that’s not broken.” Your Unix administrators may feel that Microsoft’s entry into the directory services arena is a venture warranting caution. With this option, you avoid the replacement of your current DNS, as well as additional effort and political warfare.

Figure 3. Option 3, the approach most companies will take, involves implementing a new namespace from the root domain and setting Win2K DNS as the primary master for the new zone.

You can delegate a new Win2K DNS namespace from the existing DNS structure. When a DNS namespace is delegated from an existing DNS tree, the DNS server that owns the zone file for the newly delegated namespace becomes the primary master for that namespace. The DNS zone name should correspond to the AD root domain. This is recommended if you want the benefits of the Win2K DNS server. You can continue using the existing DNS server without delegating the AD namespace as long as current DNS servers support the SRV records and dynamic updates.

One advantage of this option is that your initial integration efforts will be minimized. Because your current DNS root is Unix-based (say, corp.com), you can configure a subdomain (such as Win2K.corp.com) and create a new zone strictly for your Win2K clients. Another advantage is that you reduce AD’s dependence on your current DNS and avoid any potential incompatibility problems. Again, any integration will demand significant testing and documentation.

A disadvantage to this option is that it requires a separate namespace for Win2K logons. This may increase administrative overhead in the long run, including managing dual DNS services. However, companies running DNS on BIND are familiar with distributed or “localized” DNS support, so hierarchical support of DNS as mentioned in this option is quite common already. As a result, many companies will likely choose this integration solution.

The Windows Perspective

The simple truth for Unix advocates is that if you design your systems the Microsoft way—implementing only Microsoft DNS servers around your campus or enterprise supporting Win2K clients—it does work.

Unfortunately, the world of DNS isn’t so simple, and non-Microsoft clients may not welcome the new DNS with open arms. You don’t have to implement Microsoft DNS to implement AD, but you’ll miss out on many features of AD by not doing so.

Microsoft believes strongly that the following features of Win2K DNS make it a good choice for enterprises looking to implement a reliable hierarchical distributed network environment:

• AD integration.
• Incremental zone transfer.
• Dynamic update and secure dynamic update.
• Unicode character support.
• Enhanced domain locator.
• Enhanced caching resolver service.
• Enhanced DNS manager.
• Record scavenging.

Still, with all its new features, AD-integrated DNS remains to be implemented on any full production level. Therefore, it’s difficult to determine if security or support problems never considered will crop up. Remember, some of the Unix Internet DNS servers in your environment are currently stable and secure. Add to this the fact that many Unix mavens feel that Microsoft tends to “alter” existing technologies and preface them with their name (such as, Microsoft TCP/IP or Microsoft DNS) and you understand their concern. The goal of a standard is to have it apply to as many clients as possible, and Microsoft is forcing itself into cutting-edge territory with its latest release. This may prompt strong arguments from your DNS team. Just be ready.

There’s no doubt you’ll face many challenges in integrating AD and Win2K DNS into your existing DNS structure. Now that you have a better understanding of the pros and cons, you can decide which option will work best. Remember, by implementing later releases of BIND, you can provide a strong, functional DNS infrastructure to plan for your AD implementation.