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.

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.

Understanding Microsoft DNS
The Domain Name System is a distributed and hierarchical database that provides scalability and hostname-to-IP address resolution. The hostname must be a fully qualified domain name (FQDN) or a domain name that resolves to a particular IP address. Windows 2000 uses DNS, rather than WINS, to integrate with the Internet. DNS is composed of domains, name servers, and zones. Top-level domains such as .edu, .com, and .org are subdivided and delegated to other organizations (, to form subdomains. These subdomains are further split into zones (, for example). A large company will contain many zones, which are maintained by local DNS servers and administrators.

Microsoft DNS features include many recent standards, including:

  • Secure dynamic updates.
  • Incremental zone transfer (IXFR), which allows only changes in the zone table to be replicated, thereby reducing network traffic.
  • Notification-driven zone transfers, which allow the master server to notify secondary servers of an update and prompt them for immediate replication.
  • Record aging.
  • Ability to load server configuration from Directory Service.

Some recent proprietary features include:

  • Unicode Character support (not particularly a much-requested feature, but noteworthy).
  • AD-integrated zones, which allow zones updated by a domain controller (DC) running DNS to be stored in AD. This is proprietary to Windows 2000 DNS.

There’s a significant advantage to storing your Microsoft DNS information in AD. In standard DNS, replication is single master, pulling updates to secondary servers. This leaves a single point of failure, and many companies implement primary and backup DNS servers. However, by implementing AD storage of DNS, replication is multi-master, since AD replicates between the domain controllers running DNS on your network. With AD storage of Microsoft DNS, there’s no need to manage a separate replication structure; transfers are secure (managed by trusts in AD); and there’s no single point of failure. You can also send standard zone transfers to other servers as necessary. With AD storage, DNS data is converted to an object model in which a DNS name becomes the object and the resource record set is the attribute.

Performance and manageability advantages can push you to seriously consider the integration of DNS with AD—with a few caveats. For one, only primary zones can be AD-integrated, so the DNS zone must be running Win2K, not BIND or NetWare NDS. Only domain controllers can host AD-integrated zones, although you can have read/write access from any client loaded with the DNS snap-in. Another is the manual process of importing current zone files into Win2K DNS. The only current method for doing this is to move the pre-created zone file in the systemroot\system32\dns folder and then indicate the use of that zone file when you set up the zone as primary. Then you can convert this zone to an AD-integrated zone.

—Kevin Kocis

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 ( 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.

DNS Requests for Comment
A Request for Comment (RFC) is a draft of a work in progress that can become a standard. You can read a multitude of drafts relevant to Win2K DNS. For more information on these and other RFC and draft documents, visit

These standards are important because they affect how your current DNS infrastructure will integrate with Win2K DNS. Based on the current standards and specifications of your DNS environment (I'll assume you're running some Unix DNS domains somewhere in your enterprise), you'll have three integration options, as I discuss in the main article. Here's a short list of standards and proposed standards:

  • 1034: Domain Names—Concepts and Facilities.
  • 1035: Domain Names—Implementation and Specification.
  • 1123: Requirements for Internet Hosts—Application and Support.
  • 1886: DNS Extensions to Support IP Version 6.
  • 1995: Incremental Zone Transfer in DNS.
  • 1996: A Mechanism for Prompt DNS Notification of Zone Changes.
  • 2782: A DNS RR for specifying the location of services (DNS SRV).
  • 2136: Dynamic Updates in the Domain Name System (DNS UPDATE).
  • 2137: Secure Domain Name System Dynamic Update.
  • 2181: Clarifications to the DNS Specification.
  • 2308: Negative Caching of DNS Queries (DNS NCACHE).

—Kevin Kocis

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.

BIND Developments
  • Originally developed by US Defense Advanced Research Projects Administration (DARPA). Versions through 4.8.3 maintained by the Computer Systems Research Group (CSRG) at UC Berkeley.
  • Kevin Dunlap, a Digital Equipment Corp. (DEC) employee worked on BIND from 1985 to 1987.
  • BIND 4.9 and 4.9.1 released by DEC. Paul Vixie, then a DEC employee, became BIND's primary caretaker.
  • BIND 4.9.2 was sponsored by Vixie Enterprises with Vixie acting as BIND's principal architect/programmer.
  • BIND 4.9.3 and later have been developed and maintained by the Internet Software Consortium with support from sponsors. No more development of
  • BIND 4 is planned.
  • BIND 4.9.6 supports SRV records (minimum requirements for Win2K DNS integration).
  • BIND 8 released May 1997. Bind 8.1.1 and 8.1.2 evolved from this version and supported dynamic updates (recommended for Win2K DNS integration).
  • BIND 8.2 released January 1999. BIND 8.2.x supported incremental zone transfers (also recommended for Win2K DNS integration).
  • BIND version 9 is major architectural revision in nearly all aspects of the underlying BIND architecture, necessitated by the expected demands of domain name system growth. Added security and scalability are key components of the new version. Beta 1 is currently available.

—Kevin Kocis

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,, you can configure a subdomain (such as 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.

Berkeley Internet Name Domain is the most popular DNS implementation. BIND was written by Kevin Dunlap for the 4.3BSD Unix operating system as an implementation of DNS. Since its early release, BIND has been ported to most versions of Unix as well as NT. Currently, BIND is maintained by the Internet Software Consortium (

The most recent version of BIND is 8.2.2 (with BIND 9 in beta at the writing of this article). However, its preceding versions (4.9.x) remain the most common. Newer Unix operating systems ship with newer versions of BIND. It’s important to note that since most DNS servers have been maintained for some time, many host companies haven’t completed an upgrade to 8.2.2 (though they should for its dynamic update security features and patches). This is a manual, time-consuming process, given the number of Unix DNS servers in many companies. It’s not impossible though.

The minimum DNS requirement for AD integration is support of SRV resource records. BIND 4.9.6 and later versions meet this requirement. However, I strongly recommend upgrading to at least 8.x to support dynamic updates. Note that BIND 8.2.2 supports integration with AD including dynamic updates, zone transfers, and updating SRV records.

The Dynamic Update Protocol (RFC 2136) allows hosts to register domain names and IP addresses with the name service, which in turn allows for automatic namespace updates and alleviates manual administrative updates—important if you’re using DHCP to assign dynamic IP addresses.

The Incremental Zone Transfer Protocol (RFC 1995) allows for incremental updates in the zone transfer process as opposed to transferring the entire zone file. This protocol alleviates bandwidth demands during zone transfers.

The Service Location Resource Record (RFC 2782) allows services to be to be published in DNS by specifying the location of the server(s) for a specific protocol and domain The SRV record is used to locate AD services such as LDAP at port 389. It doesn’t use round-robin as an A record query would.

To determine if your version of BIND supports dynamic record updates, use the nsupdate tool that ships with BIND. You can create a test domain and its zone file in your DNS server, then turn on dynamic updating using the nsupdate tool to perform manual dynamic updates.

—Kevin Kocis

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.

comments powered by Disqus
Most   Popular