- Integrating DNS with Active Directory
- Heterogeneous Environments
- DNS and WINS
- About This Article
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Heterogeneous Environments
In the real world, DNS has been managed effectively on UNIX servers for years. Many UNIX administrators see no added value to implementing Microsoft DNS. This section addresses some of the issues from both perspectives.
This section discusses the issues that may arise when Microsoft DNS servers are used in a mixed environment with non-Microsoft DNS servers. Because the Microsoft DNS server is RFC-compliant, it is fully interoperable with all other RFC-compliant DNS servers. However, because the Microsoft DNS server provides a wider spectrum of features than specified in the RFC, you are advised to exercise caution when using these features. These features are limited to the use of Windows Internet Name Services (WINS), WINSR resource records, and UTF-8 character encoding.
Using WINS and WINSR Records
Because currently only Microsoft DNS servers support the WINS and WINSR resource records, I recommend disabling replication of these records if all the following conditions are satisfied:
-
The primary copy of the zone contains one of these records.
-
At least one of the secondaries resides on a non-Microsoft DNS server.
At the same time, if the secondaries reside partially on Microsoft and non-Microsoft DNS servers, disabling WINS and WINSR resource records replication may require manual input of these records to the secondary zones residing on the Microsoft DNS servers.
Using UTF-8 Characters Format
The Windows 2000 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 might 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.
Receiving Non-RFC–Compliant Data
If an Active Directory domain controller supports a secondary zone and receives unknown resource records, it drops such records and continues zone replication. The secondary server also drops circular CNAME resource records if it receives them.
UNIX/BIND
Storing your Microsoft DNS information in Active Directory offers a significant advantage. In standard DNS, replication is single master, pushing updates to secondary servers. This leaves a single point of failure, so many companies implement primary and backup DNS servers. However, if you implement ADS storage of DNS, replication is multi-master because ADS replicates between the domain controllers running DNS on your network. With ADS storage of Microsoft DNS, you don't need to manage a separate replication structure, transfers are secure (managed by trusts in AD), and there is no single point of failure. You can also send standard zone transfers to other servers as necessary. With ADS 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 promote the integration of AD with DNS. There are a few caveats. For one, only primary zones can be AD-integrated, so the DNS zone must be running Windows 2000, not a third-party DNS such as BIND or NetWareDNS. 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 Windows 2000 DNS. The only current method for doing so is to move the pre-created zone file in the systemroot\system32\dns folder and then indicate to use that zone file when you set up the zone as primary. Then you can convert this zone to an AD-integrated zone.
However, despite all these new features and caveats, the challenge remains for corporations whether they will implement Microsoft DNS into their environments and how they will perform this integration.
The primary benefits for interoperability in these environments include
-
Full interoperability with other DNS server implementations that implement RFC-compliant behavior for DNS name service
-
Use of Windows DNS servers to provide DNS service on the Internet
For interoperability testing, the Windows 2000 development team has tested the Windows 2000 DNS Server service with the following versions of the Berkeley Internet Name Domain (BIND) DNS server implementation:
-
BIND 4.9.7
-
BIND 8.1.2
-
BIND 8.2
Active Directory is completely dependent on DNS. However, great challenges and significant planning go into designing an effective directory service. Perhaps the greatest of these challenges in the enterprise for Microsoft AD implementation is interoperability. Because most enterprises currently host their DNS on UNIX servers running BIND, exactly how to integrate Active Directory into this environment will prove challenging. Because clients in a Windows 2000 environment look up SRV resource records in the DNS server to locate their network's AD and services, it is important that UNIX servers have recent BIND versions installed to perform these functions.
Some of the new DNS requirements of Active Directory are as follows:
-
Support of SRV records (RFC 2782)
-
Recommended support of dynamic updates (RFC 2136)
-
Recommended support of incremental zone transfer (IXFR) (RFC 1995)
NOTE
BIND 8.2.2 or higher supports DNS extensions used by Active Directory.
Windows 2000 clients use DNS for name resolution and for locating domain controllers for logon. Down-level clients (Windows NT 4.0 and earlier, Windows 9x) rely on NetBIOS, which uses WINS, broadcast, or LMHOSTS files. WINS is used for domain controller location. Because Windows 2000 DNS is WINS-aware, a combination of DNS and WINS can be implemented in a mixed environment. Windows NT 4.0 clients can register in Windows 2000 WINS, and Windows 2000 clients can register in Windows NT 4.0 WINS.
The minimum DNS requirement for Active Directory integration is support of SRV resource records. BIND 4.9.6 and higher versions meet this requirement. However, upgrading to at least 8.x is strongly recommended to support dynamic updates. Note that BIND 8.2.2 supports integration with Active Directory, including dynamic updates, incremental zone transfers, and SRV record updates.
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—which is important if you're using DHCP to assign IP addresses dynamically.
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 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 does not use round robin as an A record query would.
To determine whether 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 you can turn on dynamic updating by using the nsupdate tool to perform manual dynamic updates.
NOTE
It is imperative that you coordinate and plan your Active Directory and UNIX DNS integration with your current DNS team.
Although implementing AD and Microsoft DNS may sound quite enticing to the Windows support team of a larger company, if you are operating in a heterogeneous environment, the debate over directory services may fall nothing short of a technological 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 to an unproven and proprietary Microsoft product? Windows DNS has raised the stakes by complying with Internet standards and 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.
Microsoft believes strongly the following features of Windows 2000 DNS make it a good choice for corporations 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
Remember that some of the UNIX Internet DNS servers in your environment are currently stable and secure. Add to this the fact that many UNIX administrators feel that Microsoft tends to "alter" existing technologies and preface them with its name (that is, Microsoft TCP/IP, Microsoft DNS), and you understand their concern.
DNS Integration Options
When you're 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 are in a larger corporation, chances are the AD service you are designing will need to be integrated into the existing DNS infrastructure. Let's take a closer look at the three options for integrating Windows 2000 DNS into your current DNS.
If you are seriously considering installing Microsoft DNS as part of your Active Directory implementation, your three options are as follows:
-
Implement Microsoft DNS in AD and replace current DNS services.
-
Integrate your UNIX DNS structure into the DNS required for Windows 2000.
-
Maintain your UNIX DNS structure with Windows 2000.
Your choice depends on a variety of variables, including your current DNS infrastructure and specifications, as well as the many pending political issues.
Windows 2000 DNS as Primary DNS
Option 1, implementing proprietary Microsoft DNS with Active Directory, is Microsoft's choice for obvious reasons. And if your company is committed to redesigning your DNS infrastructure around Windows 2000 Active Directory, this is your choice. If you have older UNIX machines running older versions of BIND (such as 4.x) and feel the upgrade process is not worthwhile based on the enterprise shift to Active Directory, consider this option. Migration from Windows NT 4.0 DNS is relatively easy.
Migrating to Windows 2000 DNS
When migrating UNIX DNS servers to the Windows 2000 DNS, you should first introduce Windows 2000 DNS servers as secondary servers. Configure a zone transfer from a master to a secondary Windows 2000 DNS server, and make sure no errors occur in the zone transfer process. You may receive errors if the Windows 2000 DNS server cannot 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 Windows 2000 DNS server.
When moving from a BIND DNS server to DNS service, however, you need to copy and rename any BIND-created zone or boot files that you intend to use with the DNS service. Also, if you continue to use a BIND boot file to provide the initial configuration settings used by the DNS service when it is started, you need to change the boot method used by the DNS service.
To migrate from BIND-based server zones to Windows 2000 DNS servers, perform the following steps:
-
At your Windows 2000 server computer, install a DNS server.
-
Using the DNS console, at the new server add secondary zones for all your existing zones hosted at the BIND-based DNS servers.
Configure the BIND servers as the master servers for each of the secondary zones you need to create. -
Initiate zone transfer at your Windows 2000 DNS servers to transfer the zones from the BIND servers.
-
After completing the zone transfers, convert any of the secondary zones to primary zones that were obtained from primary zones at the BIND servers.
-
For the other secondary zones that remain, update the master servers for those zones to use the new primary servers running Windows 2000 server.
If you continue to use your BIND DNS servers as secondary servers for zones for which your DNS server running Windows 2000 server is the primary server, you should review interoperability issues related to zone transfer for this configuration.
Keep in mind that any zone files created and stored on UNIX DNS servers that use BIND need to be manually copied from those servers to the systemroot\system32\dns folder on the computer running Windows 2000 server and appropriately renamed. BIND zone files have a different naming convention from that used by DNS servers running under the DNS service provided in Windows operating systems.
After you transfer the files, you can upgrade your secondary zones to AD-integrated zones. You should change the 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.
One disadvantage comes in the form of integration. AD-integrated zones must be stored on DCs in the same domain. If you need it to cross domains, you must create secondary zones at other DNS servers outside the domain.
BIND as Primary DNS
You can integrate your current DNS structure into the DNS required for Windows 2000. If your current DNS meets the recommended requirements for Windows 2000 and you have tested dynamic updates, you can integrate it with Active Directory. 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 incremental zone transfers, and is strongly recommended for integrating with Active Directory.
The advantage to integrating your current DNS structure into Windows 2000 DNS is that less administrative effort is required to implement. Your company can maintain its current equipment and infrastructure. UNIX and NT administrators can cohabitate, and you can focus on your Windows 2000 implementation as opposed to fighting the DNS war.
Some disadvantages are that many UNIX DNS servers are running BIND 4.x, which may create 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.
A final option is to supplement your current DNS structure with Windows 2000. 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." UNIX administrators may approach Microsoft's entry into the directory services arena very cautiously. With this option, you avoid the replacement of your current DNS, as well as additional effort.
You can delegate a new Windows 2000 DNS namespace from the existing DNS structure. When a DNS namespace is delegated off 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 ADS root domain. This is recommended if you want the benefits of the Windows 2000 DNS server. You can continue using the existing DNS server without delegating the Active Directory 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 are minimized. You don't have to revamp your entire DNS infrastructure. Because your current DNS root is UNIX-based (north-rim.com), you can configure a subdomain (w2k.north-rim.com) and create a new zone strictly for your Windows 2000 clients. Another advantage is that you reduce Active Directory'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 Windows 2000 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 opt for this integration solution.
If you are 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 are not supported—in particular, xfrnets and other directives provided with versions of BIND, such as version 8.1.1 or higher.
If you are accustomed to manually editing DNS zone files, be aware that the DNS service uses RFC-compliant notation for its supported resource records (RRs). In most cases, the DNS service interprets and loads RRs from zone files originally created for BIND DNS servers without any need for file changes. If, however, you have used nonstandard record formatting, the DNS service will detect these edits and interpret them as bad or errored zone data.
DNS Considerations for Active Directory
When you select the option to install and configure a DNS server using the Active Directory Installation Wizard, zones are created based on the DNS name you specified during the process of promoting the server to a domain controller. Other tasks might also be useful when the first server in the domain is promoted to a domain controller, such as changing the zone type from standard primary to Active Directory–integrated and changing the update policy for the zone to Allow Only Secure Updates.
If you are deploying DNS to support Active Directory, a simple method for redundancy and fault tolerance planning is to have a DNS server running on each domain controller. For each subnet, a good rule to follow is to have two Windows 2000 server computers configured as domain controllers so that they are also running as DNS servers that load and store only Active Directory–integrated zones.
By observing these guidelines for simplified DNS and Active Directory configuration, you can enable your DNS servers to fully leverage the enhanced benefits of using Active Directory and Windows 2000 DNS servers, such as integrated storage, merged replication of Active Directory and DNS data, and secure authentication when allowing dynamic updates.
Zone Transfers Between AD and BIND
When transferring a zone between two Windows 2000 DNS servers, the DNS Server service always uses a fast transfer method that uses compression. This method includes multiple resource records in each message sent to complete the transfer of the zone between servers. For Windows 2000 DNS servers, this is the default method used when initiating transfer with other DNS server implementations.
If necessary, the servers can be configured to transfer a zone using the slower uncompressed transfer format. This way, you can make successful zone transfers with DNS servers that do not support the faster transfer method, such as BIND servers prior to version 4.9.4.
When the BIND Secondaries option is checked on the Advanced tab of the server properties, no fast transfers are made (see Figure 3). By default, the check box is cleared to enable fast transfers.
){kind=link}
Enabling slow transfers to BIND servers.
Supporting Active Directory with Other DNS Server Implementations
In many large organizations, DNS is already implemented using other solutions, such as UNIX DNS servers that run legacy versions of BIND software. In some cases, these DNS servers are not equipped to support the DNS requirements for deploying Active Directory. This issue can be addressed in one of two ways:
-
Upgrade any BIND DNS servers to version 8.1.2 or higher to meet the DNS requirements for Active Directory support.
-
Use the DNS service provided with Windows 2000 server to migrate, if possible, any of your current DNS zones to Windows 2000 DNS servers.
Although the DNS service is recommended to support Active Directory, you can use other DNS server implementations for this purpose. These other implementations should support the (SRV) resource records (RFC 2782) and dynamic updates in DNS (RFC 2136).
Support for dynamic updates is recommended but not essential. Support for the SRV resource record is mandatory because it is required to provide basic DNS support to Active Directory. Windows NT Server 4.0 (updated to Service Pack 4 or higher) supports the DNS requirements of Active Directory including SRV RRs. It does not support IXFRs or dynamic updates.
Additional manual administration of SRV resource records is needed for DNS configuration support of Active Directory to function properly on a DNS server that does not support dynamic updates."
If you decide to use Windows DNS service and manage it with a split DNS configuration in which one of the following is true:
-
Existing DNS servers for root zones are not to be upgraded or migrated to other DNS solutions
-
The DNS service and Windows 2000 server are to be deployed and provide management of any DNS domain names required to register, update, and support for use with Active Directory
Then you can modify your DNS namespace design plans in either of the following ways:
-
Create a single new subdomain in your current DNS domain namespace to root your first Active Directory domain.
-
For example, if your organization has registered and is using a second-level domain name, such as north-rim.com, you can create a single subdomain such as ad.north-rim.com and use this domain to root the DNS domain namespace used by Active Directory. The DNS service is automatically configured to support Active Directory when you install the first domain controller.
-
Before you create a zone for the new subdomain at a computer running the DNS Server service, you can delegate these subdomains away at the primary zone for your second-level domain, such as north-rim.com. In some cases, you might only need to notify another DNS or UNIX system administrator in your organization to make the delegation for you.
-
Create multiple subdomains based on your DNS second-level domain to support registration of Active Directory in DNS.
For example, if your organization has a registered second-level DNS domain name already in use (such as north-rim.com), you can create additional subdomains that are delegated to Windows DNS servers and used only for registering DNS names related to Active Directory.
This method is more complex to implement but causes less change to your currently deployed DNS infrastructure that is not Windows-based. With this namespace design, you create only those additional subdomains and appropriate zones needed to support your Active Directory deployment. For example, in this configuration, the domain name north-rim.com is both the root DNS and the root Active Directory domain name for your organization.
For this configuration, you first need to create zones for the following subdomains using the DNS snap-in tool at a computer running DNS service and Windows 2000 server:
_msdcs.north-rim.com
_ldap._tcp.north-rim.com
Before these zones are created, you can delegate these subdomains away at the primary zone for your parent or second-level domain name or notify another DNS administrator who manages these zones for your organization to do so.