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
- May 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.
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 (microsoft.com,
stanford.edu) to form subdomains. These
subdomains are further split into zones
(abc.microsoft.com, 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 (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.
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 www.ietf.org.
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, 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.
In
a BIND |
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 (www.isc.org).
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.