SQL Server Magazine

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:\winnt\system32\config 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.

   Prev. page   [1] 2     next page