Table of Contents
Windows 2000 Interoperability With Network Registrar
The Microsoft Windows 2000 operating system relies heavily on DNS and to a lesser extent, DHCP. This reliance represents a significant change from previous versions of Windows NT and requires careful preparation on the part of network administrators prior to wide-scale Windows 2000 deployments. This appendix discusses the following issues:
- Identifies the correct patch levels required for Network Registrar to interoperate with Windows 2000 deployments
- Identifies the correct patch level required for Network Registrar to run on a Windows 2000 server
- Discusses the projected impact of Windows 2000 on existing networks
- Describes how Windows 2000 interoperates with DNS
- Defines recommended practices for configuring Network Registrar in Windows 2000 environments
- Identifies outstanding issues related to Network Registrar and Windows 2000 interoperation
The following Network Registrar patch levels are required to ensure a successful Windows 2000 deployment:
- Network Registrar 2.5p10 (only if still using the 2.5 release) or higher
- Network Registrar 3.0p4 (if using the normal 3.0 release train) or higher
- Network Registrar 3.0(0.3)T (if using the technology release train) or higher
Because of changes to the underlying operating system in Windows 2000, certain changes are required to the Network Registrar code base to ensure trouble-free operation on Windows 2000. If you are installing Network Registrar on a system running Windows 2000 Professional, Server, Advanced Server, or Data Center, then you should use Network Registrar Version 3.0(2)T or later.
Always check the Network Registrar release notes for current information on operating system and feature support.
For more information about how Network Registrar ensures smooth interoperation in Windows 2000, see the "Issues Related to Network Registrar in Windows 2000 Environments" section.
Windows 2000 is more than just the next operating system from Microsoft. Windows 2000 represents a significant change in desktop computing and networking technology. Because Windows 2000 relies on TCP/IP, various components of the Windows 2000 line of software can impact existing intra-networked environments.
- Windows 2000 Professional---Windows 2000 Professional is the next generation of Windows NT Workstation. Windows 2000 Professional will most likely be deployed in place of existing instances of Windows 95, Windows 98, and Windows NT Workstation. Workstations running this operating system will most likely be clients to all major network services, although they could be configured to allow the sharing of files between individuals or groups of users. In a TCP/IP network environment, most computers running this operating system will probably be configured as DHCP clients. They will function like existing Windows 95, 98, or NT Workstation systems. Windows 2000 Professional will have only a mild impact on existing intra-networked environments.
- Windows 2000 Server, Advanced Server, and Data Center---Windows 2000 Server, Advanced Server, and Data Center represent the next generation server platforms from Microsoft. Windows 2000 Server can be thought of as the direct linear descendant of Windows NT 4.0 Server. Windows 2000 Advanced Server can be thought of as the next generation of Windows NT 4.0 Enterprise Server. Windows 2000 Data Center is a new offering from Microsoft that provides the advanced functionality of Enterprise Server, along with support for eight or more processors.
- Windows 2000 offers a number of new features and design paradigms, which significantly change the level of importance of TCP/IP networking. The DNS and DHCP standards, and directory technology (LDAP) are all critical in Windows 2000. The impact of these paradigm changes will be felt across the entire IP network infrastructure. Additionally, with the new Data Center offering, Microsoft has an operating system that can compete with high-end UNIX workstations for service provider data center and network operation center (NOC) applications. The impact of these server operating systems to existing intra-networked environments will be very high.
- Windows 2000 domain controllers and Active Directory---Windows 2000 deployment requires the existence of Windows 2000 domain controllers. These are similar to Windows NT 4.0 domain controllers, with two notable exceptions. First, the distinction between primary domain controllers (PDCs) and backup domain controllers (BDCs) is now gone. Multiple domain controllers are replicated through the embedded directory technology in Windows 2000. This means that all Windows 2000 domain controllers are of equal rank. The second notable exception is the embedded directory technology, known as Active Directory. Active Directory is an integral part of the Windows 2000 operating system. It is, on the surface, a directory, similar in function to NetWare Directory Services (NDS) or any LDAP directory. However, Active Directory is embedded in Windows 2000, and unlike its competitors in the directory market space, Active Directory is packaged with Windows 2000. Hence, Active Directory, in all likelihood, will become the directory of choice for many enterprises. Also of note, Active Directory will be the first hands-on experience many enterprises have with directory technology. Any further progression toward deploying the Directory-Enabled Networks (DEN) or CIM specifications will be dramatically impacted by the embedded directory in Windows 2000.
- Windows 2000 DNS and Active Directory---Windows 2000, like Windows NT 4.0 Server before it, ships with a DNS server that can be installed and configured. The DNS server in Windows 2000 is a superset of the functionality of the Windows NT 4.0 DNS server. The major new feature of the Windows 2000 DNS server is that it can be configured to use Active Directory to store DNS information. Once configured to store information about zones in Active Directory, directory replication is used in lieu of DNS zone transfers to share information between multiple DNS servers. This provides DNS with Microsoft-proprietary functionality known as multimaster DNS. In multimaster DNS, the traditional hierarchy of master primary and slave secondary DNS servers is abandoned. Multimaster DNS allows any DNS server to accept edits to the data in a given zone. While this sounds like an appealing feature, this produces a concurrency problem. If two updates for the same data are received simultaneously, on two separate multimaster DNS servers, then there will be a name conflict in DNS. Rather than blocking the update on the way in, multimaster DNS uses a last update wins model of directory replication to synchronize multiple versions of a zone's data. In this model, the first update will be deleted by the second update. It is anticipated that Windows 2000 DNS with multimaster replication through Active Directory will have a serious impact in networks where this technology is deployed.
- Windows 2000 and other DNS servers---Microsoft has stated, and Cisco has verified in testing, that Windows 2000 does not require or necessitate the deployment of Microsoft's DNS server. See Windows 2000 Interoperability Capabilities at http://www.microsoft.com/Windows/server/Overview/features/interop.asp. Microsoft Windows 2000 can be deployed in an existing DNS infrastructure as long as the DNS server supports certain features of the DNS protocol. The core requirements for a DNS server to interoperate with Windows 2000 domains are:
- Support of dynamic DNS updates
- Support of SRV resource record types
- Versions of BIND prior to 8.2 do not support these features. Hence, Windows 2000 deployments stand to have an extreme impact on some sites, because support of Windows 2000 will necessitate mass upgrades of DNS servers to modern RFC-compliant versions of BIND, or to a commercially supported DNS solution, such as Network Registrar.
- Existing Network Registrar users will need to upgrade their Network Registrar installations to the required patch levels, as indicated in the previous section.
The Windows domain hierarchy changes significantly in Windows 2000. In Windows NT 4.0, computer and user information was stored in domain controllers, which were advertised to the network through Windows Internet Name Service (WINS) servers. In Windows 2000, rather than storing this information in a proprietary server, it is stored in a DNS server, using a standard RFC-compliant protocol. This is significant because it means that the Windows 2000 domain space and the DNS domain space are now inseparable.
In an enterprise using Windows NT 4.0 domain controllers, Figure F-1 might represent their DNS name space and Windows NT 4.0 domain space:
Figure F-1: Hierarchical DNS Structure with Amorphous Windows NT 4.0 Domain Structure
There is no compulsory overlap between the hierarchical design of the DNS name space and nonhierarchical design of the Windows NT domain space. Windows NT domains can be created independent of any interaction with DNS and vice versa.
In a Windows 2000 environment, the DNS name space and the Windows domain space must overlap. Each Windows 2000 domain must have a DNS domain associated with it, in a 1:1 relationship. For instance, in the above examples, the Windows 2000 domains might be represented in DNS as shown in Figure F-2.
Figure F-2: Hierarchical DNS and Overlapping Windows 2000 Domain Structure
Each Windows 2000 domain must also be a DNS domain. However, it is not necessary for each DNS domain to be a Windows 2000 domain. In many enterprises, this will require a ground-up re-engineering of the DNS or the Windows NT domain space.
Windows 2000 is heavily reliant on the DNS protocol for the advertisement of services to the network. This is a fundamental change from prior releases of Windows and requires some in-depth explanation.
- The RFC defines the format of the SRV record (DNS type code 33) as:
Service.Proto.Name TTL Class SRV Priority Weisght Port Target
- There should always be an A-Record associated with the SRV record's target, so that the client can resolve the service back to a host. In the Microsoft Windows 2000 implementation of SRV records, the records might look like this:
myserver.example.com A 10.100.200.11
_ldap._tcp.example.com SRV 0 0 389 myserver.example.com
_kdc._tcp.example.com SRV 0 0 88 myserver.example.com
_ldap._tcp.dc_msdcs.example.com SRV 0 0 88 myserver.example.com
- These SRV records are automatically placed in DNS by the Windows 2000 domain controllers.
- When the Windows 2000 domain controller boots on the network, it performs the following steps to register itself in DNS and advertise its services to the network:
(a) Queries DNS asking for the start of authority (SOA) record for the DNS domain with the same name as its Windows 2000 domain
(b) Identifies the primary DNS server for the DNS zone (from the SOA record) associated with its Windows 2000 domain name
(c) Queries the primary DNS server for its Windows 2000 domain name, to ensure that the zone exists
(d) Creates a series of SRV records in this zone using the RFC 2136 dynamic DNS update protocol
08/10/1999 16:25:09 name/dns/1 Activity Protocol 0 Added type 33 record to name "_ldap._tcp.w2k.example.com", zone "w2k.example.com"
08/10/1999 16:25:09 name/dns/1 Activity Protocol 0 Update of zone "w2k.example.com" from address [10.100.200.2] succeeded.
- This log shows only one dynamic DNS update for a single SRV record. A Windows 2000 domain controller will typically register 17 of these SRV records when it boots up on the network.
- Prior to launching the net-login process, the client queries DNS with a service name, such as _ldap._tcp.dc_msdcs.example.com. The DNS server then returns the target portion of the SRV record, for example, my-domain-controller.example.com. The Windows 2000 client then queries DNS with the hostname my-domain-controller.example.com. DNS then returns the IP address of this host, and the client uses this IP address to find the domain controller. Without the existence of these SRV records, the net-login process will fail.
Most Windows 2000 deployments will be migrations from Windows NT 4.0 environments. Cisco suggests that the existing Windows NT 4.0 domain structure be preserved wherever possible. The following rules and recommendations make Windows 2000 deployments more manageable.
- Every Windows 2000 domain must have a corresponding DNS zone.
- Windows 2000 domains must not violate naming conventions for DNS hostnames.
- Do not create an NT domain for a top-level DNS domain (such as example.com). Instead, create a sub-domain, such as w2k.example.com.
- Statically configure the IP addresses of all Windows 2000 domain controllers.
- Change existing Windows NT 4.0 domain names to support DNS naming conventions.
- Where necessary, create new DNS zones for Windows 2000 domains.
Because the Windows 2000 domain space overlaps with the DNS name space, certain naming restrictions apply to Windows 2000 domains. Section 2.3.1 of RFC 1035 Domain Names Implementation and Specification (Mockapetris), defines naming conventions for hostnames and domain names. Because of the dependence on DNS domain names, these same naming conventions apply to Windows 2000 domains.
- Hostnames and domain names in DNS are not case sensitive.
- Hostnames must:
- Start with a letter
- End with a letter or a digit
- Contain internal characters that are letters, digits, or hyphens
Therefore, many characters commonly used in Windows NT 4.0 domain names should not be used for Windows 2000 domain names. Characters that should not be used in Windows 2000 domain names include the underscore ( _), at symbol (@), and ampersand (&), all commonly used in Windows NT 4.0 domain names. Also, mixed case domain names are no longer useful. For example, Windows 2000 recognizes ExampleDomain as the same as exampledomain.
Cisco recommends that all Windows 2000 domain controllers advertising their services to the network with DNS SRV records should be statically configured with an acceptable IP address for the subnet on which the server resides. This procedure allows the use of static IP address access control lists (ACLs) for dynamic DNS updates to the relevant DNS zones.
In some cases, a new DNS zone must be created for a Windows 2000 domain controller to use. If this is the case, the desired zone can be created as a sub-domain on an existing Network Registrar DNS server. For instance, to support a Windows 2000 domain of the name w2k.example.com, you should create a DNS zone of the same name. Once you have created this zone, configure it to accept dynamic DNS updates, as described below.
You can configure the DNS server in Network Registrar to allow Windows 2000 domain controllers to dynamically register their services in DNS, and thereby to advertise themselves to the network. Because this process is done through RFC-compliant dynamic DNS updates, nothing out of the ordinary must be done to Network Registrar. Network Registrar was the first DNS server to implement dynamic DNS updates and has supported SRV records since Network Registrar Version 2.0.
To configure Network Registrar to accept these dynamic SRV record updates, do the following:
Step 1 Determine the IP addresses of the devices in the network that need to advertise services through DNS.
Step 2 If they do not exist already, create the appropriate forward and reverse zones for the Windows 2000 domains.
Step 3 In the appropriate forward and reverse (in-addr.arpa) zones, enable dynamic DNS updates from the appropriate IP addresses. Perform these steps:
(a) Click on the zone in question.
(b) Click Show Properties.
(c) Click the DHCP tab.
(d) Click Enable dynamic DNS updates.
(e) In the Accept updates from these addresses only column, enter the IP addresses of all IP hosts that will be attempting to register dynamic DNS updates with the DNS server (Figure F-3).
This is usually the DHCP server or servers and any instances of Windows 2000 domain controllers. This assumes that the Windows 2000 domain controllers are configured with static IP addresses.
Figure F-3: The DNS Allowed Updaters List DHCP Tab
In this example, the w2k.example.com zone accepts only dynamic DNS updates from the IP addresses 10.100.200.1, 10.100.200.12 and 10.100.201.2.
In many cases, it may be impractical or impossible to enter the list of all the IP addresses from which a DNS server must accept updates. You can configure Network Registrar to accept updates from a range of addresses, although Cisco does not recommend this configuration.
Step 4 In the Accept updates from these addresses only column, enter a range of IP addresses defined at a class boundary. Enter a network number with a trailing zero.
For example, to accept updates from any IP host in the 10.100.200.0/24 network, enter 10.100.200.0 in the Accept updates from... list. To accept updates from any IP host in the 10.100.0.0/16 network, enter 10.100.0.0. This allows all Windows 2000 domain controllers, whose IP address is within a given class C or class B network, to register their dynamic SRV records with DNS (Figure F-4).
Figure F-4: Wildcard DNS Allowed Updaters List
In this example, the DNS domain controller accepts updates from any host in the class C networks 10.100.200.0/24 and 10.100.201.0/24.
Note Network Registrar uses IP address ACLs to control access to the creation of dynamic resource records. Cisco recommends that you enter the IP addresses of all Windows 2000 servers statically.
The following list of issues concerns interoperability between Windows 2000 (Beta 3 and Release Candidate 1) and Network Registrar. This list is intended to inform Network Registrar users of possible problems before they are encountered in the field.
- Type this command to view all dynamic DNS resource records in a given zone:
nrcmd> zone myzone listRR dynamic myfile
- This command pipes the output of the listRR command to the file myfile.
- The output of this command will look like this:
100 Ok
Dynamic Resource Records
_ldap._tcp.test-lab._sites 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com.
_ldap._tcp.test-lab._sites.gc._msdcs 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com.
_kerberos._tcp.test-lab._sites.dc._msdcs 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com.
_ldap._tcp.test-lab._sites.dc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com.
_ldap._tcp 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com.
_kerberos._tcp.test-lab._sites 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com.
_ldap._tcp.pdc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com.
_ldap._tcp.gc._msdcs 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com.
_ldap._tcp.1ca176bc-86bf-46f1-8a0f-235ab891bcd2.domains._msdcs 600 IN SRV
0 100 389 CNR-MKT-1.w2k.example.com.
e5b0e667-27c8-44f7-bd76-6b8385c74bd7._msdcs 600 IN CNAME CNR-MKT-1.w2k.example.com.
_kerberos._tcp.dc._msdcs 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com.
_ldap._tcp.dc._msdcs 600 IN SRV 0 100 389 CNR-MKT-1.w2k.example.com.
_kerberos._tcp 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com.
_gc._tcp 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com.
_kerberos._udp 600 IN SRV 0 100 88 CNR-MKT-1.w2k.example.com.
_kpasswd._tcp 600 IN SRV 0 100 464 CNR-MKT-1.w2k.example.com.
_kpasswd._udp 600 IN SRV 0 100 464 CNR-MKT-1.w2k.example.com.
gc._msdcs 600 IN A 10.100.200.2
_gc._tcp.test-lab._sites 600 IN SRV 0 100 3268 CNR-MKT-1.w2k.example.com.
- You can delete dynamically generated resource records by typing this command:
nrcmd> zone myzone removeDynRR myname
- Additionally, you can use the publicly available tool nslookup to verify the existence of dynamically generated resource records. The most commonly available version of nslookup is version 4.0 from Microsoft. You cannot use this version to look up SRV records. However you can use nslookup version 5.x, which ships with Windows 2000, to view dynamic SRV records. In this version, use the set type=SRV command to enable viewing SRV records.
- DNS resolver list for domain controllers---A Windows 2000 domain controller has to register itself in DNS using dynamic DNS updates. The DNS RFCs dictate that only a primary DNS server for a particular zone can accept edits to the zone data. Hence, the Windows 2000 domain controller has to discover which DNS server is used primary for the zone corresponding to its Windows 2000 domain name.
- The Windows 2000 domain controller discovers this by querying the first DNS server in its resolver list (configured in the TCP/IP properties control panel). The initial query is for the SOA record for the zone corresponding to the domain controller's Windows 2000 domain. The SOA record contains the name of the primary DNS server for the zone. Once the Windows 2000 domain controller has the name of the primary DNS server for its domain, it then begins sending dynamic DNS updates to this server to create the necessary SRV records.
- System administrators should ensure that the name of the primary DNS server for a zone is in the SOA record for that zone.
- Failure of A-Name DDNS updates---When a Windows 2000 domain controller attempts to advertise itself to the network, it sends several dynamic DNS updates to the DNS server of record for its domain. Most of these update requests are for SRV records. However, the domain controller also requests an update for a single A-Record of the same name as the domain.
- For example, the Windows 2000 domain controller may control the domain w2k.example.com. In this case, the DNS server must have a zone file called w2K.example.com. When booting, the Windows 2000 domain controller sends several SRV records, then a request for a single dynamic A-Record update.
- The Network Registrar DNS server then refuses this update. The data for w2k.example.com already exists and is static data. By rule, the Network Registrar DNS server does not allow a dynamic update to edit static data. If a name has been created statically with any type of resource record, no dynamic update for that name is accepted, even for a different resource record type. This is to prevent possible security infractions, such as a dynamic host registering itself as www.example.com and spoofing Web traffic to a site. When the Windows 2000 domain controller boots, a DNS log file entry such as the following appears:
08/10/1999 16:35:33 name/dns/1 Info Protocol 0 Error - REFUSED - Update of static name "w2k.example.com", from address [10.100.200.2]
- This is how Network Registrar responds to dynamic updates of static DNS data. Additionally, this dynamic DNS update failure can be ignored. Windows clients do not use this A-Record. Allocation of domain controllers is done through the SRV records. The A-Record was added by Microsoft to serve as a hook for non-Microsoft users of the domain controller.
- Windows 2000 RC1 DHCP client---Microsoft released Windows 2000 build 2072 (known as RC1) with a broken DHCP client. This client sends a misformed packet that Network Registrar cannot parse. The packet is dropped and a DHCP client running Windows 2000 RC1 cannot be served a DHCP address by Network Registrar. Microsoft delivered a patch to early deployment customers shortly after RC1 was released. However, there may be a significant number of Windows 2000 installations that do not have this patch installed.
- If a Windows 2000 system with the Release Candidate 1 DHCP client attempts to get a DHCP lease from a Network Registrar DHCP server, it will be unsuccessful. The Network Registrar DHCP server logs the following error:
08/10/1999 14:56:23 name/dhcp/1 Activity Protocol 0 10.0.0.15 Lease offered to Host:'My-Computer' CID: 01:00:a0:24:1a:b0:d8 packet'R15' until True, 10 Aug 1999 14:58:23 -0400. 301 ms.
08/10/1999 14:56:23 name/dhcp/1 Warning Protocol 0 Unable to find necessary Client information in packet from MAC address:'1,6,00:a0:24:1a:b0:d8'. Packet dropped!
- Future releases of Network Registrar (Versions 2.5P10, 3.0P4, 3.0(0.3)T, and 3.0(1)T) will have error checking specifically designed to deal with errors in the DHCP client, such as this improperly built Fully Qualified Domain Name (FQDN) option. However, if you encounter this problem, install the Microsoft patch to the RC1 client on the DHCP client. You must obtain this patch from Microsoft.
- Windows 2000 plug-and-play network interface card (NIC) configuration---If configured to use DHCP, a Windows 2000 system attempts to obtain a DHCP lease on startup. If no DHCP server is available, Windows 2000 may automatically configure the computers interface with a plug-and-play IP address. This address is not an address configured by or selected by the network administrator or by the DHCP server.
- These plug and play addresses are in the range 169.254.0.0/16. If devices in this address range are seen on a network, it means that Windows 2000 auto-configured the interfaces because it was unable to obtain a lease from a DHCP server.
- This can cause significant network and troubleshooting problems. The Windows 2000 system will no longer inform the user that the DHCP client was unable to obtain a lease. Everything will appear to function normally, but the client will not be able to route packets off its local subnet. Additionally, a Network Registrar administrator may see the DHCP client attempting to operate on the network with an address from the 169.254.0.0/16 network. The administrator might be led to think that the Network Registrar DHCP server is broken and is handing out the wrong range of IP addresses.
- If this problem occurs, perform these steps:
(a) Ensure that the DHCP client has an active network port and a properly configured NIC.
(b) Ensure that the network between the client and the DHCP server(s) are properly configured; that is, make sure all router interfaces are configured with the correct IPHelper address.
(c) Reboot the DHCP client.
(d) If necessary, watch the Network Registrar DHCP log file to see if any information is logged. If the DHCP client can successfully route packets to the Network Registrar server, then a DHCP DISCOVER is logged, even if the packet is not answered by Network Registrar.
- If the network is correctly configured, and if the DHCP client is not broken, Network Registrar should receive the packet and log it. If there is no log entry for a packet receipt, then there is a problem somewhere else in the network.
- DNS server freeze---Under certain circumstances, Windows 2000 environments can cause the Network Registrar DNS server to use 100 percent of the server's CPU for short periods. This is due to a bug in early versions of the Network Registrar software, which is encountered when the DNS server attempts to build a query-response containing large numbers of identical SRV records. This bug was fixed in releases 3.0P4 and 3.0(0.3)T. This problem causes periodic DNS server freezing.
The following online sources contain more information about Windows 2000 compliance.
- Versions of the Network Registrar Product Document set, as well as various technical documents at http://www.cisco.com/go/cnr
- Information on Microsoft Windows NT and Windows 2000 at the Microsoft Web site, http://www.miscrosoft.com
- Complete text of these RFCs referenced in this document at http://www.ietf.org:
- RFC 2052---A DNS RR for specifying the location of services (DNS SRV)
- RFC 1035---Domain names: Implementation and Specification
- RFC 2136---Dynamic Updates in the Domain Name System (DNS UPDATE)
Posted: Thu Feb 3 11:09:54 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.
