Integrating UNIX DNS with Windows 2000

Option 1: Migration
After you check your UNIX DNS implementation for SRV RR and dynamic update support, you'll likely discover that your implementation doesn't provide this support. An easy way to support the deployment of Win2K in your company is to migrate your current DNS service to Win2K DNS. Win2K DNS supports SRV RRs, dynamic updates, and AD integration.

The migration procedure is straightforward. You install a standalone Win2K server before you install a domain controller and AD. Install Win2K DNS service on the standalone server from the Networking Services dialog box. Copy the forward and reverse lookup zone files from your UNIX DNS server to the C:\winnt\system32\dns directory on the new Win2K DNS server.

You can use FTP to transfer the files from UNIX to Win2K. If you're not sure where the old zone files are in the UNIX machine, the directory statement in the named.boot or named.conf file in the /etc directory tells you which directory holds the zone files. UNIX DNS administrators often use a filename that starts with db to represent a zone file (e.g., db.acme). By default, Win2K uses a filename with a .dns extension to express a zone file (e.g., acme.com.dns), but you can use a different file-naming convention or use the old UNIX DNS zone filenames in Win2K DNS.

If your AD domain name is different from the UNIX DNS domain name, you must switch to the AD domain name for Win2K DNS. Change the old domain name in the copied zone files that are now on the Win2K DNS server to the new domain name.

You're now ready to create a new zone in the Win2K DNS administrative tool for each zone file that you copied from your UNIX DNS server. After you enter the domain name (e.g., acme.com), the New Zone Wizard prompts you to create a new zone file or use an existing zone file, as Screen 1 shows. Select the Use this existing file option, and enter the zone filename that you copied from UNIX to Win2K or the zone filename that you modified from the UNIX zone filename, such as db.acme or acme.com.dns. In the next screen, you select this DNS server to be the primary server that holds the master copy of the created zone. (BIND often calls this primary server the primary master server.) After you migrate the old zone file to the Win2K DNS server, you need to change the Allow dynamic updates setting to Yes in the General tab of the zone file's properties to enable dynamic updates for the zone. By default, Win2K sets this option to No. To enable load balancing and fault tolerance, you need to set up at least one secondary DNS server for each forward and reverse lookup zone.

With Win2K's DNS service in place, you can implement AD. If you promote a Win2K server that hosts the DNS server to a domain controller, you can integrate the DNS server into AD. All AD-integrated DNS servers are primary master servers, which store the zone information in AD and replicate one another through AD's multimaster replication mechanism. An AD-integrated DNS server also supports secure dynamic updates; this support lets you define which Win2K clients can perform a dynamic update.

If your intranet DNS servers are also your Internet name servers, you need to ask InterNIC (http://rs.internic.net) to change your domain registration to your new server names and IP addresses. In addition, you need to ask the American Registry for Internet Numbers (ARIN—http://www.arin.net) to change your IN-ADDR registration to the new name servers for reverse lookup on the Internet.

New Win2K clients and other clients can now use the new DNS servers. If you still have clients that use DHCP, you simply change old DNS server addresses to the new DNS server addresses in the DHCP server's configuration. The old client receives the new DNS server addresses the next time the client renews its IP address or the user restarts the computer.

Option 2: Coexistence
Most companies running a UNIX DNS service have heterogeneous OS environments that include Linux, Novell NetWare, UNIX, and Windows systems. To minimize the interruption to non-Windows users when you deploy Win2K, you can create a DNS subdomain and dedicate it to AD. AD doesn't require a two-level domain name such as acme.com. You can set up your AD root domain as a subdomain (e.g., win2k.acme.com) in your company's UNIX DNS hierarchy. In Figure 1, win2k is a subdomain of the Acme Corporation's existing DNS system. The win2k subdomain uses the Win2K DNS service.

For the Win2K DNS service to function in the new subdomain, you need to create a separate DNS zone for the subdomain and delegate the subdomain to at least one Win2K DNS server. This DNS server becomes an authoritative name server and provides DNS service for the subdomain. For example, if you install two name servers, ns1.win2k.acme.com and ns2.win2k.acme.com, for the subdomain win2k.acme.com, you can delegate the subdomain to both name servers in the acme.com domain. The two name servers become authoritative name servers for the subdomain win2k.acme.com and provide fault tolerance and load balancing.

You complete the delegation by adding an NS record for the subdomain to the parent domain's zone file. For example, to delegate the subdomain win2k.acme.com to the name server ns1.win2k.acme.com in the acme.com domain, you enter the following BIND statement in the zone file of acme.com:

win2k	86400	IN  NS  ns1.win2k.acme.com.

You also need to include an A record for the host ns1.win2k.acme.com in the acme.com zone file.

Next, you need to set up a reverse lookup zone for the Win2K subnet. If your Win2K systems will reside on a separate subnet, you can use Win2K DNS servers to perform reverse lookups of host names. If your Win2K and non-Windows computers reside on the same subnet, you need to use your UNIX DNS systems as name servers for reverse lookup zones or switch to Win2K DNS. If you don't plan to use Win2K DHCP to dynamically register PTR records, you can continue to use UNIX DNS for reverse lookup. If you plan to take advantage of Win2K DNS's dynamic PTR record updates and your UNIX DNS server doesn't support this functionality, you need to switch to a Win2K DNS server for reverse lookup.

Alternatively, Win2K and UNIX DNS servers can work together as primary and secondary name servers for the same zone. For example, in Figure 1, the Win2K DNS server that primarily serves the win2k subdomain can be a secondary name server for the acme .com zone. Using this setup, a Win2K user in win2k.acme.com can quickly resolve a UNIX host name from the local Win2K DNS server. If your UNIX DNS server supports SRV RRs, you can set up a UNIX name server as a secondary name server of the AD domain. However, if the UNIX DNS server doesn't support dynamic updates, don't make that server an authoritative name server for the zone. When a DNS client sends a dynamic update to the zone's authoritative name server, the authoritative server forwards the update to the zone's primary master server for a zone update. If an authoritative name server doesn't support dynamic updates, it can't understand or service an arriving dynamic update request. A UNIX DNS server can be a secondary server to a Win2K DNS server even if the Win2K DNS server is AD-integrated. However, an AD-integrated DNS server can't be a secondary name server.

Option 3: Only UNIX DNS
Companies that have long run UNIX DNS servers might regard the network naming service as a part of UNIX administration and intend to use UNIX DNS throughout and after a Win2K deployment. If you're managing the UNIX DNS service for such a company, you probably need to upgrade your UNIX DNS servers to a version that supports SRV RR and dynamic updates because Win2K and AD require this support. BIND is the most popular UNIX DNS implementation, so I'll focus on upgrading and using BIND to support Win2K. If you want to use an alternative UNIX DNS implementation, consult the vendor and request a new DNS version that supports SRV RRs and dynamic updates.

Developers at the University of California at Berkeley originally wrote BIND. ISC now maintains and develops BIND and has ported BIND to almost all UNIX platforms, including Linux. ISC has also ported BIND 8.2.2, which is the most recent version, to NT. ISC is developing BIND 9, which will change the underlying BIND architecture to support fast-growing Internet zones (e.g., .com) and include additional new features. As I discussed previously, BIND 8.2.2 fully supports Win2K. BIND is open-source freeware that you can download from ISC's FTP server (ftp://ftp.isc.org/isc/bind/src).

After you unzip and tar (i.e., archive) the BIND distribution file, you'll find BIND source code located in the src directory under the directory you saved the BIND distribution file in. In the src/port directory, you'll find about 20 directories, such as solaris and winnt. Each OS-named directory contains a makefile file that lets you use a C compiler from your OS vendor or GNU's GCC compiler (http://www.gnu.org) to easily compile BIND for your OS platform. The INSTALL file in the src directory includes instructions for compiling and installing BIND for your OS.

BIND 8.x uses a different configuration filename than BIND 4.x uses. In BIND 4.x, the configuration file is named.boot, and in BIND 8.x, the configuration file is named.conf. This file specifies the location of zone files, sets global and zone-specific parameters, and instructs the BIND server to read and load zone files when the named daemon starts. This file is often in the /etc directory. BIND 8.x also uses a different syntax in named.conf than BIND 4.x uses in named.boot. Listing 1 shows an example of a BIND 8.2.2 named.conf file. If you upgraded from BIND 4.x to BIND 8.2.2, you need to convert named.boot to named.conf. Fortunately, BIND 8.2.2 offers a bind-bootconf shell script in the src/bin/namedbootconf directory to convert named.boot to named.conf without a manual modification.

By default, BIND 8.2.2 disables dynamic updates. You must enable the dynamic update function per zone. To enable dynamic updates in a zone, you need to add an allow-update {address_match_list} statement to the zone's section of BIND's named.conf file. You can use an existing zone or create a new zone based on your AD design. The IP addresses in the allow-update address match list tell the system which hosts in the list to authenticate for dynamic updates. For example, in Listing 1, named.conf allows only hosts in the subnet 192.168.1/24 to dynamically update the forward lookup zone acme.com and reverse lookup zone 1.168.192.in-addr.arpa. However, this authentication method doesn't fend off attacks. Attackers can use a host listed in the address match list to attack a dynamic zone by sending a dynamic update request that deletes an important record or all records in the zone. To ensure DNS data authentication and integrity, RFC 2065 implemented DNS Security (DNSSEC) extensions in BIND 8.2.2. Unfortunately, Win2K doesn't support DNSSEC, so you can't use DNSSEC in BIND 8.2.2 in a Win2K deployment.

The format of a zone file in BIND 4.x and BIND 8.x is the same. However, to support negative caching of DNS queries (functionality that RFC 2308 standardized), BIND 8.2 and later use the seventh parameter in a System Object Access (SOA) record (i.e., minimum TTL) as an explicit negative caching TTL parameter. If a DNS resolver tries to query a nonexistent record, the negative caching TTL parameter tells the DNS resolver how long to cache the information stating that the resource record doesn't exist. BIND 8.1 and earlier versions that don't support RFC 2308 traditionally use the minimum TTL parameter as the default positive caching TTL value for resource records without an explicit TTL value. This positive caching TTL parameter lets a DNS resolver cache a resolved record in the amount of time that the parameter specifies. When you use an old zone file (i.e., a BIND 8.1 or earlier zone file) for BIND 8.2.2, you need to add a $TTL directive (e.g., $TTL 86400) to specify a default positive caching TTL value in the zone file. The $TTL directive placed before the SOA record becomes the default positive caching TTL value for all records in that zone. If you don't add a $TTL directive, BIND 8.2.2 uses the negative caching TTL value as the positive caching TTL value, and the negative caching TTL value is usually much smaller than the positive caching TTL.

After you make necessary changes to the named.conf file and zone files, you can start or restart the named daemon so that it uses the new configuration and zone files. You might want to use the BIND nsupdate utility first to ensure that your DNS server supports dynamic updates. After you verify your server's support, your BIND DNS server is ready to accept dynamic updates from Win2K systems. When BIND receives a dynamic update, it saves the update in a log file whose name corresponds with the zone name (e.g., db.acme.log) and updates the DNS data in memory. BIND updates the zone file periodically (about once an hour) and removes the old log file when BIND commits the update. In this way, BIND aggregates dynamic updates to a batch process rather than updating the zone file every time BIND receives a dynamic update. This mechanism can simultaneously handle numerous updates.

When you use dynamic updates for a zone in BIND, don't manually modify the zone file. BIND sets the zone file attribute to read-only after it updates the zone, so any manual changes you make between zone updates will be lost. If you need to add, remove, or modify a record, you can use the nsupdate utility to manually send a dynamic update request to the zone.

BIND 8.2 and later support incremental zone transfer (RFC 1995 defines this functionality), which lets a secondary name server (a slave name server in BIND 8.x terminology) transfer only changes rather than an entire update. The BIND master server maintains the changes between one SOA serial number and the next in a zone's .ixfr file (e.g., db.acme.ixfr). When a slave server requests an incremental zone transfer, the master server transfers only the changes. Win2K DNS supports incremental zone transfer.

Ready, Set, Go
Now that you have a better understanding of Win2K's DNS requirements, you can decide which option will work best to integrate your UNIX DNS service and Win2K. After you set up a functional DNS infrastructure that supports SRV RR and dynamic updates, you're ready to deploy Win2K and AD. This setup lets you take advantage of Win2K's enhancements and build your network applications around AD.