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 IntegrationThe 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 FilesBIND 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 TypesAs 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 ConsiderationsSecurity 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 FilesWhen 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 BINDYou 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 CreationAlthough 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:
_udp
_tcp
_sites
_msdcs 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: WarningEvent Source: NETLOGONEvent Category: NoneEvent ID: 5773 Date: 3/29/2001 Time: 11:45:25 AM User: N/A Computer: DC1Description:
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 FilesEvery 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 ConsiderationsSo, 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 FormatThe 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 DataIf 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 DecisionAlthough 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.
