Integrating UNIX DNS with Windows 2000

Should you migrate to Win2k DNS or continue to use UNIX DNS?

DNS is a standard name-resolution mechanism that an IP host uses to name, advertise, and locate IP hosts and services on the Internet and over an intranet. To fully integrate Windows 2000 (Win2K) into the Internet, Microsoft used standard DNS rather than WINS as Win2K's native naming service. In addition, Microsoft has implemented Dynamic DNS (DDNS) to let Win2K systems dynamically register their names and IP addresses in a DDNS server. Dynamic updates of machine information eliminate the administrative burden of maintaining a static database in a traditional DNS server. Win2K domain controllers also dynamically register their service resource records (SRV RRs) in DDNS servers. Clients in a Win2K network look up SRV RRs in the DDNS server to locate the network's Active Directory (AD) and its services (e.g., logon service).

Internet Engineering Task Force (IETF) Request for Comments (RFC) 2052 documents SRV RRs, and RFC 2136 documents DDNS updates. SRV RR and DDNS updates aren't new to the family of DNS standards—IETF published RFC 2052 in October 1996 and RFC 2136 in April 1997. However, Win2K's use of these features challenges companies that have long run DNS on UNIX machines to map host names and IP addresses. Most of these companies haven't upgraded to the most recent version of Internet Software Consortium's (ISC's) Berkeley Internet Name Domain (BIND) 8.2.2 or to a new DNS version from their UNIX and DNS vendors that supports both SRV RR and dynamic updates. If this scenario describes your company and you're planning a Win2K deployment, you face an immediate integration question: Should you migrate to Win2K DNS or continue to use UNIX DNS? You have three options: migrate to Win2K DNS, create an environment in which UNIX and Win2K DNS coexist, or use only UNIX DNS.

Before I delve into these options, I describe how Win2K uses SRV RRs to help you better understand the benefits and drawbacks of each option and dispel any confusion about SRV RRs' use of underscores. Understanding Win2K's dynamic updates and how to examine your UNIX DNS server's dynamic update support will also help you decide which option is best for your company.

SRV RRs in Win2K Windows NT clients don't need to specify an NT domain controller when they log on to an NT domain. NT WINS provides a domain controller to the client for logon. This setup lets clients access an NT domain as long as one domain controller is available, even if all other domain controllers have failed. Win2K inherited this functionality and lets clients log on to an AD domain without specifying a domain controller. However, to provide this service to its clients, Win2K uses DNS rather than WINS. (Win2K provides WINS for backward compatibility.) When a Win2K client system logs on, it queries the DNS server for the domain controllers of the logon domain. Win2K uses SRV RRs to locate the logon service, then sends the client the domain controllers' names. The client uses an available domain controller to log on to the AD domain.

SRV RRs provide a general mechanism for advertising and locating Internet services. For example, suppose acme.com is your company's Web server. Pointing an SRV RR of _http._tcp.acme.com to webdev.acme.com lets you enable an SRV RR-capable browser to use http://acme.com instead of http://webdev.acme.com to access your Web server. The SRV RR will instruct the browser to use the webdev.acme.com server. This functionality means you don't need a Canonical Name (CNAME) of webdev.acme.com in the acme.com DNS domain, so you can easily move the Web service from one server to another without a hassle. SRV RRs also enable load balancing and fault tolerance when you associate two or more servers with the same service.

Let's take a look at how Win2K uses SRV RRs. If the AD domain (i.e., DNS domain) acme.com contains two domain controllers, w2kdc1 and w2kdc2, Win2K uses two SRV RRs for the Lightweight Directory Access Protocol (LDAP) service in the acme.com domain. The following SRV RRs advertise and locate the two LDAP-enabled domain controllers in the acme.com domain: _ldap._tcp.acme.com. 600 IN SRV 0 100 389 w2kdc1.acme.com. and _ldap._tcp.acme.com. 600 IN SRV 0 100 389 w2kdc2.acme.com. When a client queries _ldap _tcp.acme.com looking for a domain controller, acme.com's DNS server will send the client these two records. The client picks either w2kdc1.acme.com or w2kdc2.acme.com as the domain controller and uses the LDAP protocol at TCP port 389 to communicate with the domain controller.

The client chooses a domain controller based on the parameters in the SRV RRs and the domain controllers' availability. A DNS server and Win2K system cache receive DNS records. The number that follows the protocol and domain name (i.e., 600 in my example) is the caching Time to Live (TTL) value. For example, Win2K can cache the records in my example for 600 seconds (i.e., 10 minutes). The number following SRV (i.e., 0 in my example records) shows the record's priority. The smaller the number, the higher the priority. The number that follows the priority (i.e., 100 in my example records) shows the record's weight. The larger the number, the heavier the weight. If multiple same-service records have the same priority but different weights, the client prefers a record with a heavier weight. If multiple same-service records have the same priority and weight, the client communicates with the domain controllers in a round-robin fashion. If the client can't connect to a chosen domain controller, the client goes to the next preferred domain controller. In this way, SRV RRs provide load balancing and fault tolerance.

Win2K also uses SRV RRs to advertise and locate domain controllers in a specific domain, domain controllers in a specific site, a PDC in a specific domain (for a mixed-mode Win2K and NT installation), Global Catalog (GC) servers in a specific domain, GC servers in a specific site, Kerberos Key Distribution Centers (KDCs) in a specific domain, and Kerberos KDCs in a specific site. The Microsoft article "DNS Records Registered by Windows 2000 Domain Controllers" (http://support.microsoft.com/support/kb/articles/q178/1/69.asp) documents the SRV RRs that domain controllers register in DNS.

Some users complain about Microsoft's use of underscores (_) in Win2K's SRV RRs because some UNIX DNS implementations don't accept underscores. Microsoft isn't to blame for the use of underscores. In January 1999, IETF updated RFC 2052 in an Internet Draft (http://search.ietf.org/internet-drafts/ draft-ietf-dnsind-rfc2052bis-05.txt). Microsoft adopted the updated version for SVR RRs in Win2K because the new version will soon replace the old RFC. In the new version, the IETF appends an underscore to SRV RRs' service identifier and protocol name to differentiate the service identifier and protocol name from other DNS labels. The updated SRV RR format is_service._protocol.domainname. TTL Class SRV RR Priority Weight Port Host. Many UNIX DNS implementations, such as BIND 4.9.4 and later, check to ensure that host names conform to RFC 952, a host-naming standard that doesn't allow underscores in a host name. However, the first part of the updated SRV RR that contains underscores (formally called the SRV RR's owner) isn't a host name, so the underscores aren't a problem. In addition, a DNS implementation that conforms to RFC 952 doesn't check host names against an SRV RR's owner, and DNS domain names can contain underscores. In my experience, underscores in SRV RRs haven't posed a problem to BIND 8.2.2. If your version of UNIX DNS doesn't accept underscores in SRV RRs, change the check-names option on the UNIX DNS server from the default fail setting to the warn setting or the ignore the underscores setting.

DDNS in Windows 2000
To install or promote a Win2K domain controller, the domain's authoritative DNS server must support dynamic updates to correctly register the domain controller's AD and Netlogon services in DNS. The netlogon.dns file in the C:winntsystem32config directory contains about 20 SRV RR, A, and CNAME records that the domain controller needs to register on a DNS server. Win2K lets you continue a domain controller installation if the OS discovers that the DNS server doesn't support dynamic updates, but you must manually enter the records into the domain's zone file on the DNS server after the installation. If you don't want to use a DDNS server, manually registering these records might work in a Win2K network that contains a very small number of domain controllers. However, midsized and large networks should seriously consider using Win2K's DDNS or a third-party DDNS system to reduce the administrative burden of entering records and eliminate the risk of introducing errors.

Win2K client systems also use dynamic updates. When it boots, a Win2K client that has a static IP address will try to register its A and PTR records in its forward and reverse lookup zones on the DDNS server. A workstation that uses DHCP to lease a dynamic IP address will try to register its A record in the DDNS server when the workstation receives the IP address. The DHCP server will try to register the workstation's PTR record in the DDNS server for the workstation. To be backward compatible, the Win2K DHCP server will register both A and PTR records of NT and Windows 9x DHCP clients in the DDNS server. To fully use Win2K's dynamic updates, you must have a DDNS system in place when you deploy Win2K.

UNIX DNS can usually accept dynamic update requests of A, PTR, and some other kinds of records. However, UNIX DNS might not support dynamic updates of SRV RRs. For example, BIND 8.2.1 doesn't support dynamic updates of SRV RRs, and early versions of BIND 8 are unlikely to support dynamic updates of SRV RR. To support Win2K, your UNIX DNS implementation must use BIND 8.2.2 or BIND 9.

To discover whether your UNIX DNS implementation supports dynamic updates of SRV RRs, you can use the command-line nsupdate utility that comes with BIND to make a dynamic update of an SRV RR. For example, create a test domain (e.g., acme.com) and its zone file in your DNS server. Turn on the dynamic update option of the zone, and let any host dynamically update the zone. Use the nsupdate utility to manually generate a dynamic update of the SRV RR for the Web service in acme.com:

$ nsupdate> update add webdev.acme.com. 86400 IN A 192.168.1.10> update add _http._tcp.acme.com. 3600 IN SRV 0 1 80 webdev.acme.com.>

The first command starts the nsupdate tool, the second command adds the Web server's A record, the third command adds the Web service SRV RR record to the acme.com domain, and the last (blank) line instructs nsupdate to send the two dynamic updates you entered to the DNS server. After you run this command, if you can use nslookup or look in acme.com's zone file to find the two records in the memory of the DNS server, your DNS server supports dynamic updates of SRV RRs. BIND temporarily saves received dynamic updates in a zone log file, then modifies the zone file accordingly.

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:winntsystem32dns 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:

win2k86400IN  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.