DNS & Windows 2000 on Stanford Campus

 

This document addresses DNS issues for Windows 2000 computers on campus. Please send questions to Ross Wilper.

 

Windows 2000 Workstations

 

There are two documents which describe how one should configure TCP/IP on Windows 2000 workstations. They are:

 

Connecting to SUNet using Windows 2000 and a modem:

http://www.stanford.edu/group/itss/pcstanford/w2kppp.html

 

Connecting to SUNet via Windows 2000 and Ethernet:

http://www.stanford.edu/group/itss/pcstanford/w2kether.html

 

Of note in those documents is that Windows 2000 workstations and member servers should NOT be configured to use dynamic DNS registration (also called DDNS). They should also be configured to use the primary campus DNS servers, as all other campus clients do.

 

Fully Qualified DNS Name (FQDN) of Windows 2000 machines in the campus domain tree

 

Windows 2000 Domains require an associated FQDN. This is new to the Windows world, and holds implications we will cover further.

 

Windows domains in the campus domain tree have a non-regular FQDN. For example, the ITSS windows domain has a DNS domain name of it.win.stanford.edu. Workstations and member servers in the domain tree, however, still have a FQDN of netdbmachinename.stanford.edu. This is fully supported, and preferable. All machines regardless of operating system should have a host record (called a DNS A record) registered in NetDB.

 

Implications of FQDN requirement for Windows 2000 Domains

 

Windows 2000 domains require a FQDN to support ldap, kerberos, PKI certificates, and other new technologies which are now integrated with the operating system.

 

Domain controllers must have a FQDN within the FQDN of the Windows domain. Stanford.edu can NOT be the FQDN of your windows domain. There are many reasons for this, including the fact that the existing MIT K5 kerberos realm would conflict with kerberos realm of a windows domain with a name of Stanford.edu.

 

Because of the requirement to have a FQDN below the stanford.edu namespace, theWindows 2000 project has asked and received the DNS subdomain win.stanford.edu for the campus domain tree. So the FQDN of a domain controller in the ITSS Windows domain mentioned above would be netdbmachinename.it.win.stanford.edu.

 

Windows 2000 domain controllers hold authentication services and directory services. Domain controllers need to register roughly a dozen special DNS records called SRV records. These records support name resolution to support authentication and directory services. Without these records login and most domain services would be impossible. These SRV records may be registered statically or via DDNS. SRV records are supported by DNS BIND 4.96 or higher, and DDNS is supported by DNS BIND 8.12 or higher. The campus DNS servers are at a higher level, and support both functionalities. NetDB, however, does not support the creation of these records, but will in a future release.

 

Because of the lack of NetDB support for SRV records, the campus domain tree is running it’s own delegated DDNS server. Domain controllers in the campus domain tree will dynamically register their SRV records with this DDNS server. When NetDB support is made, there are plans to eliminate this DDNS server and statically register all needed records on the primary campus DNS servers. It should be noted that only domain controllers in the campus domain tree will register records on this DDNS server, and errant registrations of records from other machines won’t be accepted.

 

Clients participating in the campus domain tree will be able to find their authentication and directory services because the primary campus DNS servers which their clients are configured to use will redirect these requests to the DDNS server in the campus domain tree.

 

For those departments with Windows 2000 domains, which do not wish to participate in the campus domain tree, there may be an alternative to using DNS by using a WINS server for name resolution of some of these services, but this option is not mapped out clearly by Microsoft. At a minimum, it would appear that one would have to disable all kerberos services. We’ve been told that Microsoft won’t take support calls from trees which disable SRV record functionality, so it is clear that this is not a Microsoft recommended option.

 

References:

http://www.microsoft.com/windows2000/library/howitworks/communications/nameadrmgmt/dnsover.asp

http://www.microsoft.com/windows2000/library/howitworks/communications/nameadrmgmt/w2kdns.asp

 

Last modified by barkills at 6/11/2001 3:00 PM

©2000 Trustees of the Leland Stanford Junior University