Cisco CNS Network Registrar User's Guide, 5.5
Appendix: Windows 2000 Interoperability
Downloads: This chapterpdf (PDF - 171.0KB) The complete bookPDF (PDF - 5.45MB) | Feedback

Windows 2000 Interoperability

Table Of Contents

Windows 2000 Interoperability

Use of SRV Records and Dynamic DNS Updates

Recommended Design Practices

Rules

Suggestions

Naming Rules for Domains

Configuring Addresses for Windows 2000 Domain Controllers

Supporting Dynamic SRV Records

Issues Related to Windows 2000 Environments


Windows 2000 Interoperability


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

How Windows 2000 interoperates with DNS.

Recommended practices for configuring Network Registrar in Windows 2000 environments.

Outstanding issues related to Network Registrar and Windows 2000 interoperation.

Use of SRV Records and Dynamic DNS Updates

Windows 2000 relies heavily on the DNS protocol for advertising services to the network. This is a fundamental change from prior releases of Windows and requires some in-depth explanation. Table D-1 describes how Windows 2000 handles SRV records and dynamic DNS updates.

Table D-1 Windows 2000 SRV Records and Dynamic DNS Updates 

This feature...
Means...

SRV records

Windows 2000 domain controllers use the SRV resource record to advertise services to the network. This resource record is defined in the experimental RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)." The RFC defines the format of the SRV record (DNS type code 33) as:

_service._protocol.name ttl class SRV priority weight 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

An underscore always precedes the service and protocol names. In the example, _kdc is the Kerberos Data Center. The priority and weight help you choose between target servers providing the same service (the weight differenciating those with equal priorities). With zero priority and weight, the listed order determines the priority. Windows 2000 domain controllers automatically place these SRV records in DNS.

How SRV records are used

When a Windows 2000 client boots up, it tries to initiate the network login process to authenticate against its Windows 2000 domain controller. The client must first discover where the domain controller is, and they do so using the dynamically generated SRV records.

Before launching the net-login process, the client queries DNS with a service name, such as _ldap._tcp.dc_msdcs.example.com. The DNS server SRV record target is, for example, my-domain-controller.example.com. The Windows 2000 client then queries DNS with the hostname my-domain-controller.example.com. DNS returns the host address and the client uses this address to find the domain controller. The net-login process fails without these SRV records.

Dynamic DNS updates

When a Windows 2000 server is configured as a domain controller, you statically configure the name of the domain it manages through the Active Directory management console. This Windows 2000 domain should have a corresponding DNS zone associated with it. The domain controller should also have a series of DNS resolvers configured in its TCP/IP properties control panel.

Note The Windows 2000 domain controller dynamically registers an A record with a name that is the same as its Windows domain. Therefore, you should create a Windows 2000 domain as a domain in the subzone of its zone. For example, create the following environment:

zone—example.com.
Windows subzone—w2k.example.com.
Windows domain—local.w2k.example.com.

If the domain should be the same as the zone, contact the Cisco Technical Assistance Center for help.

 

When the Windows 2000 domain controller boots up, it performs the following steps to register itself in DNS and advertise its services to the network:

1. Queries DNS asking for the start of authority (SOA) record for the DNS domain that mostly closely encapsulates its Windows 2000 domain.

2. Identifies the primary DNS server for the DNS zone (from the SOA record) that mostly closely encapsulates its Windows 2000 domain name.

3. Creates a series of SRV records in this zone using the RFC 2136 dynamic DNS update protocol.

Server boot process log file examples

Under normal operating conditions, the Network Registrar primary DNS server writes the following log entries when a Windows 2000 domain controller boots up and creates its SRV records:

08/10/2000 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/2000 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 typically registers 17 of these SRV records when it boots up.


Recommended Design Practices

Most Windows 2000 deployments are migrations from Windows NT 4.0 environments. Cisco suggests that you preserve the existing Windows NT 4.0 domain structure wherever possible. The following rules and recommendations make Windows 2000 deployments more manageable.

Rules

Here are some rules to consider:

Every Windows 2000 domain should not map directly to a subzone but should be enclosed by one.

Windows 2000 domains must not violate naming conventions for DNS hostnames.

Suggestions

Here are some suggestions:

Do not create a Windows domain that equates to a DNS zone (such as example.com). Instead, create a subdomain, such as local.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, such as the w2k.example.com subzone and the local.w2k.example.com domain.

Naming Rules for 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") defines naming conventions for hostnames and domain names. Because of the dependence on DNS, these 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, you cannot use many characters commonly used in Windows NT 4.0 domain names for Windows 2000 domain names. Characters that you should not use 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 equivalent to exampledomain.

Configuring Addresses for Windows 2000 Domain Controllers

Cisco recommends that you should statically configure all Windows 2000 domain controllers, advertising their services to the network with DNS SRV records, with an acceptable IP address for the subnet on which the server resides. In this way, you can use static IP address access control lists (ACLs) for protection against DNS dynamic updates.

Supporting Dynamic SRV Records

You can configure the Network Registrar DNS server so that Windows 2000 domain controllers can dynamically register their services in DNS and, thereby, advertise themselves to the network. Because this process occurs through RFC-compliant dynamic DNS updates, you do not need to do anything out of the ordinary in 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.


Note Network Registrar uses IP address ACLs to control access to the creation of dynamic resource records. Cisco recommends that you statically enter the IP addresses of all Windows 2000 servers.


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, create the appropriate forward and reverse zones for the Windows 2000 domains.

Step 3 Enable dynamic DNS updates for the forward and reverse zones. Do the following:

a. Show the properties for the zone.

b. In the CLI, use the zone name enable dynamic command. In the GUI, click the DHCP tab. See Figure 6-6.

c. In the GUI, check the "Enable dynamic DNS updates" box.

d. In the CLI, use the zone name set dynupdate-set command to define the IP addresses of the hosts to which you want to restrict accepting dynamic updates. In the GUI, enter the addresses in the "Accept updates from these addresses only" fields. This is usually the DHCP servers and any Windows 2000 domain controllers. (This assumes that you configured the Windows 2000 domain controllers with static IP addresses.)

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 Using the zone name set dynupdate-set command in the CLI or the "Accept updates from these addresses only" fields in the GUI, enter a range of IP addresses defined at a class boundary. Enter a network number with a trailing zero.


Issues Related to Windows 2000 Environments

Table D-2 describes the issues concerning interoperability between Windows 2000 and Network Registrar, intended to inform you of possible problems before you encounter them in the field.

Table D-2 Issues Concerning Windows 2000 and Network Registrar Interoperability 

This issue...
Means...

Invisible dynamically created resource records

Network Registrar, when properly configured, accepts dynamic DNS updates from both DHCP and Windows 2000 servers. However, dynamic data does not appear in the Network Registrar GUI because you should not, under normal operation, edit or delete these records. However, you can use the CLI to access the dynamic portion of the DNS zone for viewing and deleting records. Enter this command to view all dynamic DNS resource records in a given zone:

nrcmd> zone myzone listRR dynamic myfile 

This redirects the output to the myfile file. See Example D-1.

You can delete dynamically generated records by entering this command:

nrcmd> zone myzone removeDynRR myname [type] 

You can also use nslookup to verify their existence, and you can use version 5.x (shipped with Windows 2000) to view dynamic SRV records. In this version, use the set type=SRV command to enable viewing SRV records.

Domain controller registration

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 the primary for the zone that includes 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 of the zone that includes the domain controller's Windows 2000 domain. The SOA record includes the name of the primary server for the zone. If no zone exists for the domain name, the domain controller keeps removing the left-most label of the domain name and sends queries until it finds an SOA record with a primary server included in that domain. Once the Windows 2000 domain controller has the name of the primary DNS server for its domain, it sends it dynamic DNS updates to create the necessary SRV records.

Ensure that the name of the primary DNS server for a zone is in its SOA record.

Failure of A record DDNS updates

When a Windows 2000 domain controller tries to advertise itself to the network, it sends several dynamic DNS update requests 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 Windows 2000 domain.

(continued)

Failure of A record DDNS updates, continued

For example, the domain controller may control the w2k.example.com Windows 2000 zone. There must be an authoritative zone that includes this host. If the Network Registrar DNS server is also authoritative for a zone identical to this Windows 2000 domain, it rejects registering its A record, because the dynamic DNS A record update conflicts with the static SOA and NS records. 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 up, a DNS log file entry such as the following appears:

08/10/2000 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, you can ignore this dynamic DNS update failure. Windows clients do not use this A record. Allocation of domain controllers happens through SRV records. Microsoft added the A record to accommodate legacy NT clients that do not support SRV records.

Note that failing to register the controller's A record slows down the domain controller's bootup process, affecting the overall login of worker clients. As mentioned earlier, the workaround is to define the Windows 2000 domain as a subdomain of the authoritative zone. If this is not possible, contact the Cisco Technical Assistance Center for help.

Windows 2000 RC1 DHCP clients

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. Network Registrar drops the packet and cannot serve the client, logging the following error:

08/10/2000 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 2000 14:58:23 -0400. 301 ms.

08/10/2000 14:56:23 name/dhcp/1 Warning Protocol 0 Unable to find 
necessary Client information in packet from MAC 
address:'1,6,00:d0:ba:d3:bd:3b'. Packet dropped!

Network Registrar includes error checking specifically designed to deal with errors such as this improperly built 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 tries to obtain a DHCP lease on startup. If no DHCP server is available, Windows 2000 may automatically configure the computer's interface with a plug-and-play IP address. This address is not an address the network administrator or DHCP server configured or selected.

(continued)

Plug-and-play NIC configuration, continued

These plug-and-play addresses are in the range 169.254.0.0/16. If you see devices in this address range on a network, it means that Windows 2000 autoconfigured the interfaces because it could not obtain a lease from a DHCP server.

This can cause significant network and troubleshooting problems. The Windows 2000 system no longer informs the user that the DHCP client could not obtain a lease. Everything appears to function normally, but the client cannot route packets off its local subnet. Additionally, you may see the DHCP client trying to operate on the network with an address from the 169.254.0.0/16 network. This may lead you to think that the Network Registrar DHCP server is broken and handing out the wrong addresses.

 

If this problem occurs, perform these steps:

1. Ensure that the DHCP client has an active network port and a properly configured NIC.

2. Ensure that the network between the client and the DHCP server(s) are properly configured. Ensure that all router interfaces are configured with the correct IPHelper address.

3. Reboot the DHCP client.

4. If necessary, look at the DHCP log file. If the DHCP client can successfully route packets to the server, this logs a DHCPDISCOVER, even if Network Registrar does not answer the packet.

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, there is a problem somewhere else in the network.

Scavenging Windows 2000 client address records

Windows 2000 clients do not clean after themselves, potentially causing their dynamic record registration to remain indefinitely. This leaves stale address records on the DNS server. To ensure that these stale records are periodically removed, you must enable scavenging for the zone. For details, see the "Scavenging Dynamic Records" section.


Example D-1 Output Showing Invisible Dynamically Created Resource Records

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.