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

Windows 2000 Interoperability

Table Of Contents

Windows 2000 Interoperability

Use of SRV Records and Dynamic DNS Updates

Recommended Design Practices

Rules and Suggestions

Naming Rules for Domains

Configuring Addresses for Windows 2000 Domain Controllers

Supporting Dynamic SRV Records

Issues Related to Windows 2000 Environments

Frequently Asked Questions


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 

Feature
Description

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 differentiating 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 host name 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.

 

When the Windows 2000 domain controller boots up, it performs these 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 these 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. These rules and recommendations make Windows 2000 deployments more manageable.

Rules and Suggestions

Consider these rules and suggestions:

Windows 2000 domains must not violate naming conventions for DNS host names.

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.

Do not allow clients to dynamically update their zones. Instead, configure the DHCP server so that it is responsible for all dynamic DNS updates.

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 host names and domain names. Because of the dependence on DNS, these naming conventions apply to Windows 2000 domains.

Host names and domain names in DNS are not case-sensitive.

Host names 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 the IP addresses of all Windows 2000 domain controllers, which advertise their services to the network with DNS SRV records. 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:


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:

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.

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

d. In the CLI, use the zone name set update-acl 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.

If it is 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. Cisco does not recommend this configuration.

Step 4 Using the zone name set update-acl 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 

Issue
Description

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 zone's primary DNS server is in its SOA record.

Failure of A record dynamic DNS 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.

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 and spoofing Web traffic to a site.

For example, the domain controller might control the w2k.example.com Windows 2000 zone. If a zone with the same name exists on the Network Registrar DNS server, these resource records could be part of that zone:

w2k.example.com. 43200 SOA nameserver.example.com.  
hostmaster.example.com.
(
98011312 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;minim
w2k.example.com.86400 NS nameserver.example.com

 

The Windows 200 domain controller would try to add an additional record, such as:

w2k.example.com. 86400 A 192.168.2.1

Network Registrar does not allow a dynamic DNS update to conflict with any statically configured name in the zone, even if the record type associated with that name is different. In the above example, an attempt to add an A record associated with the name w2k.example.com collides with the SOA and NS records.

When the Windows 2000 domain controller boots up, a DNS log file entry such as this 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, or use the DNS server's fake-ip-name-response attribute. 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 this 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.

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

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.

Frequently Asked Questions

These questions come up frequently about integrating Network Registrar DNS services with Windows 2000.

Q. What happens if both Windows 2000 clients and the DHCP server are allowed to update the same zone? Can this create the potential for stale DNS records being left in a zone? If so, what can be done about it?

A. The recommendation is not to allow Windows 2000 clients to update their zones. Instead, the DHCP server should manage all the client dynamic RR records. When configured to perform dynamic DNS updates, the DHCP server accurately manages all the resource records associated with the clients that it served leases to. In contrast, Windows 2000 client machines blindly send a daily dynamic DNS update to the server, and when removed from the network, leave a stale DNS entry behind.

Any zone being updated by dynamic DNS update clients should have DNS scavenging enabled to shorten the longevity of stale resource records left by transient Windows 2000 clients. If the DHCP server and Windows 2000 clients are both updating the same zone, three things are required in Network Registrar:

1. Enable scavenging for the zone. For details, see the "Scavenging Dynamic Records" section.

2. Configure the DHCP server to refresh its dynamic DNS update entries as each client renews its lease. By default, Network Registrar does not re-update the DNS record between its creation and its final deletion. A dynamic DNS update record that Network Registrar creates lives from the start of the lease until the lease expires. You can change this behavior using a DHCP server attribute, force-dns-updates. For example:

nrcmd> dhcp enable force-dns-updates 
100 Ok 
force-dns-updates=true 

3. If scavenging is enabled on a particular zone, then the lease time associated with clients that the DHCP server updates that zone on behalf of must be less than the sum of the no-refresh-interval and refresh-interval scavenging settings. Both of these settings default to seven days. You can set the lease time to 14 days or less if you do not change these default values.

Q. What needs to be done to integrate a Windows 2000 domain with a pre-existing DNS domain naming structure if it was decided not to have overlapping DNS and Windows 2000 domains? For example, if there is a pre-existing DNS domain called example.com and a Windows 2000 domain is created that is called w2k.example.com, what needs to be done to integrate the Windows 2000 domain with the DNS domain?

A. In the example, a tree in the Windows 2000 domain forest would have a root of w2k.example.com. There would be a DNS domain named example.com. This DNS domain would be represented by a zone named example.com. There may be additional DNS subdomains represented in this zone, but no subdomains are ever delegated out of this zone into their own zones. All the subdomains will always reside in the example.com. zone.

Q. In this case, how are dynamic DNS updates from the domain controllers dealt with?

A. To deal with the SRV record updates from the Windows 2000 domain controllers, limit dynamic DNS updates to the example.com. zone to the domain controllers by IP address only. (Later, you will also add the IP address of the DHCP server to the list.) Enable scavenging on the zone. The controllers will update SRV and A records for the w2k.example.com subdomain in the example.com zone. There is no special configuration required to deal with the A record update from each domain controller, because an A record for w2k.example.com does not conflict with the SOA, NS, or any other static record in the example.com zone.

The example.com zone then might include these records:

example.com. 43200 SOA ns.example.com. hostmaster.example.com. (
98011312 ;serial
3600 ;refresh
3600 ;retry
3600000 ;expire
43200 ) ;minimum
example.com.86400 NS ns.example.com
ns.example.com. 86400 A 10.0.0.10
_ldap._tcp.w2k.example.com. IN SRV 0 0 389 dc1.w2k.example.com
w2k.example.com 86400 A 10.0.0.25
...

Q. In this case, how are zone updates from individual Windows 2000 client machines dealt with?

A. In this scenario, the clients could potentially try to update the example.com. zone with updates to the w2k.example.com domain. The way to avoid this is to close down the zone to updates except from trusted sources. Before Network Registrar 6.0, the DNS server should be configured to accept updates from the DHCP server by IP address only. With Network Registrar 6.0, you can use transaction signatures (TSIG) between the DHCP server and the primary DNS server for the example.com zone.

Configure the DHCP server to do dynamic DNS updates to the example.com zone and the appropriate reverse zone for each client, and use option 81 to prevent the clients from doing dynamic DNS updates themselves. (See the "Configuring Dynamic DNS for a Scope" section and the "Enabling Dynamic Update on the DNS Server" section.)

Q. Has security been addressed in this case?

A. By configuring the forward and reverse zone to accept only updates from trusted IP addresses, you close the zone to updates from any other device on the network. Security by IP is not the most ideal solution, as it would not prevent a malicious attack from a spoofed IP address source. You can secure updates from the DHCP server by configuring TSIG between the DHCP server and the DNS server.

Q. Is scavenging required in this case?

A. No. Updates are only accepted from the domain controllers and the DHCP server. The DHCP server accurately maintains the life cycle of the records that they add and do not require scavenging. You can manage the domain controller dynamic entries manually by using the Network Registrar single-record dynamic resource record removal feature.

Q. What needs to be done to integrate a Windows 2000 domain that shares its namespace with a DNS domain? For example, if there is a pre-existing DNS zone called example.com and a Windows 2000 Active Directory domain called example.com needs to be deployed, how can it be done?

A. In this example, a tree in the Windows 2000 domain forest would have a root of example.com. There is a pre-existing domain that is also named example.com that is represented by a zone named example.com.

Q. In this case, how are dynamic DNS updates from individual Windows 2000 client machines dealt with?

A. To deal with the SRV record updates, create subzones for:

_tcp.example.com.
_sites.example.com.
_msdcs.example.com.
_msdcs.example.com.
_udp.example.com.

Limit dynamic DNS updates to those zones to the domain controllers by IP address only. Enable scavenging on these zones.

To deal with the A record update from each domain controller, enable a DNS server attribute, simulate-zone-top-dynupdate:

nrcmd> dns enable simulate-zone-top-dynupdate 
100 Ok 
simulate-zone-top-dynupdate=enabled 

It is not required, but if desired, manually add an A record for the domain controllers to the example.com zone.

Q. In this case, how are zone updates from individual Windows 2000 client machines dealt with?

A. In this scenario, the clients could potentially try to update the example.com zone. The way to avoid this is to close down the zone to updates except from trusted sources. Before Network Registrar 6.0, the DNS server should be configured to accept updates from the DHCP server by IP address only. As of Network Registrar 6.0, you can use transaction signatures (TSIG) between the DHCP server and the primary DNS server for the example.com zone.

Configure the DHCP server to do dynamic DNS updates to the example.com zone and the appropriate reverse zone for each client, and use option 81 to prevent the clients from doing dynamic DNS updates themselves. (See the "Configuring Dynamic DNS for a Scope" section and the "Enabling Dynamic Update on the DNS Server" section.)

Q. Has security been addressed in this case?

A. By configuring the forward and reverse zone to accept only updates from trusted IP addresses, you close the zone to updates from any other device on the network. Security by IP is not the most ideal solution, as it would not prevent a malicious attack from a spoofed IP address source. Updates from the DHCP server are more secure when TSIG is configured between the DHCP server and the DNS server.

Q. Has scavenging been addressed in this case?

A. Yes. The subzones _tcp.example.com, _sites.example.com, _msdcs.example.com, _msdcs.example.com, and _udp.example.com zones accept updates only from the domain controllers and scavenging was turned on for these zones. The example.com zone accepts dynamic DNS updates only from the DHCP server.