In-Depth
BIND Your Windows 2000 DNS
Although BIND is still the DNS champ, Windows 2000 DNS is becoming more popular. But what do you do when you need to have both on your network? An interop pro shares how to make it happen—step by step.
Here’s the scenario: You’re
a senior systems administrator for the Microsoft Windows platform in a
large, heterogeneous enterprise. Your company has the Windows camp, the
Unix camp and the networking camp. Your CIO expresses support for the
Active Directory initiative but hasn’t conclusively decided on the DNS
solution. The Unix team, which has been hosting DNS successfully for years,
is reluctant to relinquish its hold on DNS. “Can we maintain BIND and
still roll out AD?” the CIO asks.
Now your job begins.
Tastes Great! Less Filling!
The Domain Name System (DNS) is a distributed database of information
for mapping friendly names (i.e. www.north-rim.com) to IP addresses (66.210.246.4).
Berkeley Internet Name Domain (BIND) was one of the original DNS implementations,
and it’s still widely used on the Internet. Microsoft’s Active Directory
Service requires DNS, with an integrated preference for Windows 2000 DNS.
While both offer a robust name service solution, Win2K DNS offers features
specific to AD—features unavailable in current BIND versions. For this
reason, you feel it’s imperative to roll out Win2K DNS using AD-integrated
zones.
Now what? This scenario seems quite reminiscent of the famous beer commercials:
Tastes great! Less filling! Tastes great! Less filling! Only inebriation
won’t solve this issue. Ladies and gentlemen, welcome to the world of
DNS integration.
Integrating BIND and Win2K DNS may be one of the greatest challenges
of implementing AD into heterogeneous enterprises. Organizations with
BIND in use will be resistant to move to Win2K DNS, based on BIND’s popularity
and Microsoft’s previous struggles with its DNS product. DNS integration
is possible but will require collaboration from the Unix DNS team.
Are both types of DNS needed in a heterogeneous environment? The quick
answer is no. But it’s not the easy answer. Because BIND has been a long-term,
stable solution for name services in large organizations, migrating ownership
is a significant challenge. Many Unix administrators believe that Microsoft
tends to “alter” existing technologies and preface them with its name
(for example, Microsoft TCP/IP and Microsoft DNS), and Microsoft believes
its DNS solution can meet all the requirements for enterprise DNS, even
outside the scope of AD.
First Steps Toward Integration
The first step your company should take toward integration depends on
where it is today. What is your company’s current version of BIND? Version
4.9.6 is the minimal requirement for AD (to support SRV records), but
isn’t recommended. BIND version 8—specifically version 8.2.2—supports
the suggested features for integration with AD (such as support for dynamic
updates, negative caching and enhanced incremental zone transfers). If
you currently run BIND version 4.x, upgrading to version 8 is relatively
simple and requires no new domains or additional DNS servers. A new subdomain
could be created for BIND 8.x, but that isn’t much of a value-add if you’re
looking to integrate Win2K DNS.
You have three options when implementing AD and Win2K DNS into a BIND-only
enterprise. For these choices, I’m assuming the enterprise already has
a DNS name registered with InterNIC. They are:
- Make the AD domain match the current DNS domain.
- Make AD a different domain.
- Make AD a subdomain of the current DNS domain.
The best option for enterprises running BIND is to upgrade to at least
version 8.2.2 and create a new Microsoft DNS subdomain, option number
three. Without going into the elaborate decision tree, and the options
associated with each, I’ll just say this choice requires additional administrative
effort and DNS servers but provides the best solution for security and
redundancy. Now, let’s take a closer look at the DNS architectures and
how to implement this option.
BIND Configuration Files
BIND versions 8 and 9 use a two-level file hierarchy when defining zones.
The first level consists of the named.conf file, usually located in the
/etc directory on a Unix server. The named.conf file contains information
regarding general DNS configuration characteristics, such as defining
zones hosted by the name server and the source domain database file for
the zone.
The second level consists of the actual zone text files stored on either
primary or secondary DNS servers. These files include the forward lookup
zone file, the reverse lookup zone file, the cache file, and the loopback
file. Table 1 lists the file names and what they contain.
| File Name |
Description |
| Named.conf |
Boot file (formerly named.boot in
BIND 4.x) |
| db.domain_name |
Forward lookup zone. If the DNS domain
is kevinkocis.com, this file is called db.kevinkocis.com. |
| db.x.y.z |
Reverse lookup zone. If the network
is the class C network address 195.19.1, this files is called
db.195.19.1 |
| db.cache |
Root hints file that contains
the names and IP addresses for the root DNS domain name servers. |
| db.127.0.0.1 |
File for loopback address resolution
on the local server. |
|
| Table 1. Typical BIND8x and 9 configuration
files |
BIND and Win2K DNS File Types
As you would expect, the BIND and Win2K DNS naming systems for file types
differ, as their nomenclature is based on the specific server configuration.
Win2K DNS server uses the .dns suffix as opposed to the db. prefix. However,
for porting purposes, Win2K DNS server can be configured to interpret
BIND DNS db files.
Table 2 shows examples of how BIND server files are renamed for use with
the DNS service provided in Win2K Server.
| Description |
Unix
filename |
Win2K
filename |
| Boot file |
Named.boot |
Boot.dns |
| Forward lookup zone file |
db.domain_name |
domain_name.dns |
| Reverse lookup zone file |
db.x.y.z |
z.y.x.dns |
|
| Table 2. The key Unix DNS filenames,
with their Windows 2000 equivalents. |
Win2K DNS servers, however, use the fully qualified domain name (FQDN)
for the zone, which includes the in-addr.arpa domain, to complete the
filename. For example, for the class C network 192.1.10, the correct name
to use for the same zone in Win2K Server is 10.1.192.in-addr.arpa.dns
when copying and renaming the file.
Because DNS standards don’t specify the internal data structure for resource
records, the structure varies. BIND servers use zones stored in text files,
and Win2K allows the option of having AD store DNS data.
Security Considerations
Security is also different on the two platforms. BIND security mechanisms
feature more granularity on IP address and subnet restrictions than Win2K
DNS. On the other hand, Win2K DNS features more granular rights and permissions
through its security model.
In BIND, administrators can secure transactions, including DNS queries
and responses, plus zone transfer requests and dynamic updates from unauthorized
addresses. BIND 8.2 introduced DNS Security Extensions, called DNSSEC
(RFC 2535), which treat resource records as “sets” maintaining the same
TTL instead of individual records. This feature allows you to apply IP
address-based access control lists (ACLs) to queries, including ACLs applicable
to a specific zone or even zone transfer. Any authoritative name server,
primary or secondary, can apply ACLs, which restrict access through security
permissions.
While DNSSEC is based on Transaction SIGnature (TSIG), this security
isn’t compatible with the GSS-TSIG feature in Win2K Kerberos security.
Although each security model is acceptable, they’re incompatible when
integrated.
Transferring Zone Files
When migrating Unix DNS servers to the Win2K DNS, you have two options:
- Zone file transfer via FTP.
- Zone file transfer via DNS zone transfer.
The zone files can be transferred via FTP from BIND servers to Win2K
DNS servers. In this scenario, the administrator can FTP the forward and
reverse zone files from the Unix server (db.xxx files located in etc/named.boot
or etc/named.conf, depending on the BIND version) to the %system root%\winnt\system32\dns
directory on your Win2K DNS server, appropriately renamed with the .dns
suffix from the db.xxx prefix format. The file can then be used for configuring
the new zone.
If Win2K DNS will continue to use a BIND boot file to provide the initial
configuration settings used by the DNS service when started, the DNS service
boot method must be changed to point to the boot file.
The other zone file transfer method is through the DNS zone transfer.
First, you’ll need assistance from the Unix DNS team to configure the
boot file named.conf. The following entries need to be added:
- Under options, add “notify yes” for update notification to secondary
name servers.
- Under the domain zone section (i.e., north-rim.com), add “check-names
ignore.”
- Under the domain zone section, use the “allow-transfer” command to
configure zone transfer partners by IP address or range.
- Under the domain zone section, use the “allow-update” command to
configure recipients of zone updates by IP address or range.
The second entry is controversial because it allows underscore characters,
which were previously forbidden for BIND.
When transferring a zone between two Windows DNS servers, the DNS Server
service always uses a fast transfer method that uses compression. This
method includes multiple resource records (RRs) in each message sent to
complete the transfer of the zone between servers. For Win2K DNS servers,
this is the default transfer.
If necessary, Win2K DNS servers can be configured to transfer a zone
using the slower uncompressed transfer format. This enables successful
zone transfers to be made with DNS servers that don’t support the faster
transfer method, including all BIND servers before version 4.9.4.
When the BIND secondaries option in the Advanced tab of the DNS server
properties is checked, no fast transfers are made. By default, the check
box is cleared to enable fast transfers. This setting is used to optimize
zone transfers between Win2K DNS servers and other DNS server implementations,
because Win2K DNS zone transfers always use the fast transfer format.
To enable or disable fast transfer format during zone transfers, perform
the following steps:
- Open DNS Manager and right-click the DNS server.
- Select Properties and click the Advanced tab.
- In the Server Options list, select the BIND Secondaries check box
and click OK (See Figure 1).
 |
| Figure 1. In the Server Options list, select
the BIND Secondaries check box and click OK. |
Integrating Windows 2000 DNS with BIND
You can integrate your current Unix DNS structure into the DNS required
for Win2K if it meets the recommended requirements for Win2K (BIND 8.2.2
and higher). The advantage here is that less administrative effort is
required for implementation. Your organization can maintain current equipment
and infrastructure.
A disadvantage to supporting Win2K and AD in a legacy BIND environment
is that BIND 4.x creates a crossroads situation: Upgrade or convert. The
possible increase in future administrative overhead and manual data entry
may be an issue. There will also be a single point of failure for dynamic
registrations. BIND DNS servers (limited to primary and secondary zones)
don’t support AD-integrated zones.
In many large organizations, the DNS servers aren’t equipped to support
the DNS requirements for deploying AD. This issue can be resolved by upgrading
BIND DNS servers to version 8.2.2 or later, or replacing the BIND DNS
service with Win2K DNS servers.
If the existing (or recently upgraded) BIND root DNS supports AD requirements,
it can delegate a new Win2K DNS namespace that corresponds to the AD root
domain.
 |
| Figure 2. A suggested migration path. (Click
image to view larger version.) |
Delegation of a new namespace for the AD domain is recommended to maximize
the client benefits of using the Win2K DNS server. However, existing DNS
servers support SRV records, and dynamic updates don’t require an AD namespace
delegation.
One advantage of this option is that initial integration efforts will
be minimized, because the physical DNS infrastructure requires minimal
changes. Because your current DNS root is Unix-based (for example, north-rim.com),
you can configure a subdomain (w2k.north-rim.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.
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, this will be the preferred integration option for
many heterogeneous companies.
If you’re using the BIND boot file with the DNS service after migration,
other limitations apply to the use of this file by the DNS service. For
example, some BIND boot directives aren’t supported—in particular, xfrnets
(which restrict zone transfers from the primary name server to a list
of secondary name servers using an IP list or network address) and DNS
security extensions (DNSSEC) provided with versions of BIND, such as version
8.1.1 or later.
Tip: When manually editing DNS zone files, be aware that the
DNS service uses RFC-compliant notation for its supported resource records.
In most cases, the DNS service interprets and loads records from zone
files originally created for BIND DNS servers without any need for file
changes. If, however, you have used non-standard record formatting, the
DNS service can detect these edits and interpret them as bad or erroneous
zone data.
Subdomain Creation
Although the integration of AD can succeed with non-Microsoft DNS servers
(for example, BIND 8.2.2), Microsoft strongly recommends that you use
Win2K’s DNS server because it adds several features to the standard RFCs
that aren’t necessarily found in non-Microsoft DNS servers. These features
include integration with WINS, dynamic registration of down-level clients
with the help of Win2K DHCP server, and support for UTF-8 characters (mentioned
later in this article under “Disadvantages and Considerations”).
You can modify your DNS namespace by creating a new single DNS subdomain
for AD or by creating multiple subdomains based on a registered second-level
domain name.
For example, north-rim.com is registered to North Rim Inc.; the BIND
DNS administrator can create the delegation from the primary zone. Then,
the AD administrator can create a single subdomain such as ad.north-rim.com
to implement as the root to the DNS domain namespace used by AD.
Creating multiple subdomains based on a DNS second-level domain to support
registration of AD in DNS is more complex. In this scenario, the administrator
would create additional subdomains delegated to Win2K DNS servers for
registering DNS names related to AD.
This scenario allows for less impact and change to the current non-Windows
DNS infrastructure. With this namespace design, you create only those
additional subdomains and appropriate zones needed to support your AD
deployment. For example, the domain name north-rim.com is both the root
DNS and the root AD domain name.
In this situation, delegation from the primary zone for the following
zones needs to be created on the BIND DNS server:
- _msdcs.north-rim.com
- _ldap._tcp.north-rim.com
After this process, create these subdomains using the Win2K DNS Manager.
To integrate Win2K DNS into an existing namespace based on non-dynamic
DNS servers, you can delegate the subdomains used by the SRV locator records
to support dynamic updates. To allow this option, perform the following
steps:
- On the non-dynamic BIND DNS server authoritative for the zone with
the name of the AD domain, delegate the following zones to a Win2K-based
server running DNS:
For example, if the root zone is called north-rim.com, delegate _udp.north-rim.com,
_tcp.north-rim.com, _sites.north-rim.com, and _msdcs.north-rim.com to
the Win2K DNS server.
- Next, create the forward zones delegated in the preceding
step on the Win2K DNS server and enable the zones for dynamic update.
Be sure to include the underscore on the zone name field in the New
Zone Wizard.
- Also, a single zone or several zones may be created and configured
to allow clients and servers to dynamically register themselves with
the Win2K DNS server. For example, a zone called dynreg.north-rim.com
could be configured for dynamic registrations. To configure such a zone,
perform the following steps:
- Delegate a new zone from the non-dynamic DNS server (authoritative
for the parent zone) to the Win2K DNS server. For example, delegate
the dynreg.north-rim.com zone to the Win2K server.
- Create a forward lookup zone for the delegated zone on the Win2K
DNS server (dynreg.north-rim.com).
- Enable the zone for dynamic updates.
- Reset clients and servers will have to register themselves in the
new zone because, by default, they’ll register themselves in a DNS zone
with the same name as the Win2K domain where they’re members. To reconfigure
the clients and servers, perform the following steps:
- Right-click My Computer, click Properties, then click the Network
Identification tab.
- Click Properties, then More.
- Click to clear the “Change Primary DNS Suffix When Domain Membership
Changes” check box.
- Type the appropriate zone name in the Primary DNS Suffix of This
Computer box, for example, dynreg.north-rim.com.
- Click OK.
This change requires that the client be rebooted after the change’s
completion. After reboot, it will dynamically register itself in the
new zone.
When Win2K domain controllers start, the netlogon service tries registering
several SRV records in the authoritative zone. Because the zones for registering
SRV records have been delegated (in steps 1 and 2) to a Win2K server where
they can be dynamically updated, these registration attempts will succeed.
Also, a DC will attempt to register the host records (A) listed in its
netlogon.dns file in the root zone (north-rim.com). Because the root zone
is on a non-dynamic DNS server, these updates won’t succeed and will generate
an event in the system log on the DC similar to the following:
Event Type: Warning
Event Source: NETLOGON
Event Category: None
Event ID: 5773
Date: 3/29/2001
Time: 11:45:25 AM
User: N/A
Computer: DC1
Description:
The DNS server for this DC doesn’t support dynamic DNS. Add the DNS records
from the file “%System Root%\System32\Config\netlogon.dns” to the DNS
server serving the domain referenced in that file.
Netlogon.dns Files
Every Win2K DC has a netlogon.dns file located in its “%SystemRoot%\
System32\Config” folder, containing a list of DNS records the DC will
attempt to register when the netlogon service starts.
Caution: You should make a copy of this file
before making the following changes so that an original list of the records
can be maintained. Each DC will have different records specific to each
DC’s network adapter.
Examine the netlogon.dns file for host records in the file. For example:
- north-rim.com. 600 IN A 192.168.1.1
- gc._msdcs.north-rim.com. 600 IN A 192.168.1.1
The number of host records in the netlogon.dns file depends on the number
of adapters the DC has, the number of configured IP addresses for each
adapter, and the DC’s role. The host records are calculated as such:
- The name server totals one host record for each of its IP addresses
for the domain name.
- Also, if the DC is also a global catalog (GC) server, it registers
gc._msdcs. for each IP address on the server.
As I mentioned earlier, the non-dynamic BIND DNS server won’t accept
dynamic registrations from any Win2K DC. Therefore, the DC’s host records
have to be configured manually on the authoritative DNS server for the
root zone. The addition of the host record isn’t required unless third-party
LDAP clients that don’t support SRV DNS records are searching for the
DCs.
The following registry key should be used to disable the DC from attempting
to register the A records seen in the net-logon.dns file. In the Registry,
change the REG_DWORD RegisterDns ARecords value to 0 (zero) under:
HKLM\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters
After you have an AD forest and domain in place, you should integrate
AD with the DNS domains the Win2K server running DNS is responsible for.
Also, you should reconfigure zones that have been configured to accept
dynamic updates to accept only secure dynamic updates.
Disadvantages and Considerations
So, now you’re integrating. The CEO is happy. The Unix team is collaborating
and agrees to the delegation option. What could go wrong?
Win2K DNS is RFC-compliant and interoperable with all other RFC-compliant
DNS servers. But, because it offers a wider spectrum of features than
specified in the RFC, you should exercise caution when using these features,
which include WINS and WINS-R resource records, UTF-8 character encoding
and Non-RFC Compliant BIND Data.
Using WINS and WINS-R Records
Because currently only Microsoft DNS servers support the WINS and WINS-R
resource records, you should disable replication of these records if a)
the primary copy of the zone contains one of these records, and b) at
least one of the secondaries resides on the non-Microsoft DNS server.
At the same time, if the secondaries reside partially on Microsoft and
non-Microsoft DNS servers, disabling WINS and WINS-R resource records
replication may require manual input of these records to the secondary
zones residing on the Microsoft DNS servers.
To disable replication of WINS and WINS-R records, perform the following
steps:
- In the DNS Manager, expand the server and right-select either the
forward or reverse lookup zone.
- Right-click the zone for which you want to disable replication of
WINS and WINS-R records and then click Properties.
- Select the WINS tab.
- Select the Do Not Replicate This Record check box.
If WINS and WINS-R record replication is disabled, only queries directed
at the primary servers will provide results to the querying client. Queries
directed at secondary servers will prompt the response that the name wasn’t
found.
Using UTF-8 Characters Format
The Win2K DNS server can be configured to allow or disallow the use of
UTF-8 characters on a per-server or per-zone basis. A non-UTF-8-aware
DNS server may accept a zone transfer of a zone containing UTF-8 names,
but it may not be able to write back those names to a zone file or reload
those names from a zone file. Administrators should exercise caution when
transferring a zone containing UTF-8 names to a non-UTF-8-aware DNS server.
Non-RFC-Compliant BIND Data
If a Win2K server supports a secondary zone and receives unknown resource
records, such as DNSSEC records, it will drop such records and continue
zone replication. The Win2K DNS server also drops circular CNAME resource
records upon receipt.
Integration
Issues
You're Going to Run Into |
|
• Political. The politics circling the issue of multiple
DNS systems may affect any possible DNS integration.
Unix and PC camps are usually long entrenched, and this
shows no signs of remediation. Also, the CEO/CIO or
senior manager’s background (Unix or PC roots) may direct
the integration one way or another.
• Internal DNS ownership and standards. If your company
already has DNS, there’s a strong chance that the Unix
camp supports it and has standards and processes associated
with its ownership. Integrating Microsoft DNS into the
picture will require an overhaul or lengthy addendum
to the process and documentation.
• Administrative overhead. Systems engineers from the
Unix and Windows camps will need get up to speed on
how each other’s DNS systems work to integrate properly,
which may require formal or informal training. Also,
you’ll need to roll out more DNS servers and transfer
zone data.
• Increased cost. New machines may be required to run
as Windows 2000 DCs hosting DNS. However, these costs
should have been absorbed by your Active Directory rollout
plan.
• Internal and external namespace issues. Although
not covered thoroughly in this article, the decision
of internal and external namespace can seriously affect
DNS integration. Here I’ve focused on a subdomain for
AD; however, some companies may elect to maintain the
same namespace internally and externally, which creates
some administrative overhead and redundancy, but is
quite possible.
• For those companies that can’t reach a consensus,
it wouldn’t hurt to consider a third-party IP address
management software solution such as Lucent Technologies’s
QIP or Check Point Software Technology’s MetaIP, both
of which are platform-independent and can be administered
from either camp.
—Kevin Kocis
|
|
|
Making the Decision
Although integrating Win2K DNS server and AD into existing BIND environments
may seem challenging, the job is doable. Each DNS server has its share
of security enhancements, dynamic registration, and standard RFC features.
The decision on which of the three integration options for Win2K to implement
will most likely be based more on political and social considerations
than on technical concerns.
The migration paths from BIND DNS to Win2K DNS can be complicated and
will require significant testing in a lab. Also, integration will undoubtedly
decrease a level of available features in each DNS system, because security
and fast transfers are incompatible features of each.