Name Registration and Resolution in Windows NT

Windows IT Pro

- Advertise

Name Registration and Resolution in Windows NT
View the book table of contents

Author:	Emmett Dulaney Vijay Sankar Sharon E. Sankar
Published:	June 1999
Copyright:	1999
Publisher:	29th Street Press

Abstract
This chapter offers an in-depth look at name registration and resolution in a Windows NT network environment. The chapter also looks at the differences between DNS Manager for NT 4.0 and DNS Manger for Windows 2000 Server.

Name registration and name resolution are complementary processes, and the terms are sometimes (erroneously) used interchangeably. Name registration is the process by which a remote computer announces to the rest of the network what its name is and that it is available. Name resolution is the method by which a local computer discovers which remote computer it is supposed to communicate with.

For example, consider a typical task that involves name resolution — opening a file on a remote system from a local system. The main steps in this process are

Find out which device the file is on.
Locate the remote machine where the device is located.
Determine how to send a request to that machine.
Find out which file system is used on the remote device.
Find out where on the file system the file is located.

In a Windows NT environment, locating a remote machine — the name resolution part of the process — can be accomplished in a number of ways.

From simplest to most complex, they are

NetBIOS broadcasts
HOSTS files
LMHOSTS files
Domain Name Server (DNS)
Windows Internet Name Service (WINS)
Dynamic DNS

Table 6.1 gives you a quick comparison of these six different methods.

The variety of name registration and resolution schemes, and how they behave on different Windows operating systems, can be confusing, especially if you are deploying NT for the very first time. Many factors — such as the network size, the number of users, the link speeds, the geographical makeup and the kinds of computers that make up the organizational network — play a part in deciding the best registration and resolution scheme to use.

Small NetBIOS LANs can probably handle all name registration and resolution issues with broadcasts. A small homogenous IP network may be able to make do with simple HOSTS files and statically assigned IP addresses. A large, heterogeneous, geographically separated network may require a combination of different name resolution schemes and name servers.

In the sections that follow, we first distinguish between the two names a computer has, then we describe each name resolution method and discuss how each is used on the network to resolve names. We also describe, where applicable, how these services can be integrated with Unix.

Because much of the setup information is included in Microsoft’s Windows NT Server Networking Guide Version 4.0, we don’t reiterate what it says. We focus, instead, on the complex or new aspects of name resolution and use real-world examples.

NAMES

All NT computers up to and including NT 4.0 have two names — a NetBIOS name (also called a computer name) used by applications written according to the NetBIOS API and a host name (also called a DNS name) used by Windows Sockets and Posix-compliant applications.

NetBIOS Names
To display the NetBIOS name as shown in Figure 6.1, right-click Network Neighborhood, then choose Properties. The Identification tab shows the Computer Name (NetBIOS name).

To find all the NetBIOS names registered for a particular computer, type nbtstat -n at a DOS prompt to display the NetBIOS Local Name Table (Figure 6.2), which provides the name, type of name, and status. The names listed in Figure 6.2 show that the user, Administrator, is logged on to an NT computer called ActiveX4 that is member of a domain called Projects. The other names refer to the NetBIOS names of some of the services that are running on this computer. For example, the ActiveX4 name with a type of <03> Unique is the Messenger Service name for the computer, and the ActiveX4 name with a type of <20> Unique is the Server Service name.

Host Names
To display the host name as shown in Figure 6.3, from the dialog box in Figure 6.1, switch to the Protocols tab, select TCP/IP, click Properties, and switch to the DNS tab.

By default, the host name and the NetBIOS name for a computer are the same. To accommodate this default behavior, you must follow both the NetBIOS and DNS naming rules listed below.

Keep computer names 15 characters or less. If the computer name is longer than 15 characters, NetBIOS applications won’t work. (NetBIOS names are actually 16 characters long. Microsoft Networking reserves the 16th character to designate the type of name.)
Don’t use underscores; they aren’t valid in DNS names. If you use computer names containing underscores, DNS servers based on Unix and other operating systems won’t work properly.
Don’t use periods inside names. NT assumes that any name with a period is a DNS name and not a NetBIOS name.

Special Note: It’s important to understand that the host name in Figure 6.3 is simply toshnt and not toshnt.foretell.ca. Toshnt.foretell.ca is the fully-qualified domain name for the computer, toshnt is the host name, and foretell.ca is the domain name. To make matters even more confusing, fully-qualified domain names are also known as DNS names because they are used by the DNS name resolution method.

NETBIOS BROADCASTS

A NetBIOS broadcast is a communication from the one computer to all other computers on the network for purposes of trying to resolve a name. Each computer on the network receives the broadcast and checks to see whether it has the unresolved name. While a NetBIOS broadcast will succeed on a local network, it doesn’t usually work over routed networks because most routers aren’t configured to forward NetBIOS broadcasts.

Name Resolution Problems

When you’re troubleshooting name resolution problems — for example, computer or resource not found — for performance reasons, it is important to identify first whether the unresolved name is a NetBIOS name or a host name. Applications like Network Neighborhood, the NET commands, and Windows Explorer use the NetBIOS API and hence rely on NetBIOS name resolution.

Browsers such as Netscape Navigator, database programs such as Microsoft SQL Server, and mail clients such as Microsoft Outlook are written using the Windows Sockets API; they rely on host names.

Host name resolution initially referred to the process of resolving TCP/IP resources that don’t use NetBIOS resources. Because of the convergence of different technologies — NetBIOS networking, Windows networking, and TCP/IP networking — we now use all the resolution methods; however, the order differs depending on whether it is a NetBIOS resolution or a host name resolution being attempted.

HOSTS FILES

A HOSTS file resides in the systemroot\system32\drivers\etc directory and contains the IP addresses of machines paired with their fully-qualified domain names. Figure 6.4 shows an example of a HOSTS file.

This HOSTS file closely follows the Unix host file structure; for example, sbs01 is an alias for sbs01.foretell.ca, and everything after the # sign is a comment. HOSTS files are effective for small, stable TCP/IP-based networks that seldom add or change resources. If a computer is added, deleted, or moved to a new domain, every computer must have its HOSTS file revised — a time-consuming task for a network of, say, 100 computers.

HOSTS files used for name resolution can be placed on computers running Windows NT, Windows for Workgroups, Windows 95/98, DOS or OS/2, and Unix. To create a HOSTS file, open the systemroot\system32\drivers\etc directory and create a file called hosts (a sample file in this directory is included on NT machines).

Caution: If you are accustomed to Unix systems where the TCP/IP stack automatically uses the HOSTS file, it’s important to note the following, as pointed out by Dr. Sidnie Feit: In the Windows environment on machines where you want the TCP/IP stack to consult the HOSTS files, you must select “Enable DNS for Windows Resolution” on the WINS Address tab for NT systems or “Enable DNS” in the Network Properties dialog box on Windows 95 systems.

LMHOSTS FILES

Using LMHOSTS files is a more complex but more easily administered method of name resolution than using HOSTS files because LMHOSTS files can be implemented centrally. An LMHOSTS file resolves NetBIOS names and is not intended to resolve host names.

The LMHOSTS file, like the HOSTS file, resides in the systemroot\system32\drivers\etc directory, and a sample file is included with NT machines. Figure 6.5 shows a typical LMHOSTS file.

Like HOSTS files, an LMHOSTS file must reside on each computer. The difference, however, is that you can use an #INCLUDE statement in the LMHOSTS file to make it possible for a computer to read and parse the LMHOSTS files of other computers. In Figure 6.5, for example, the #INCLUDE statement includes the LMHOSTS file located on computer prtsrv in the shared directory named public. (Note that to include this LMHOSTS file, it is also necessary for prtsrv’s name and IP address to be preloaded into the NetBIOS name cache using the #PRE statement.)

When you include other computers’ LMHOSTS files in an LMHOSTS file, a change made to the LMHOSTS file of one computer can be propagated to all other computers that have that LMHOSTS file listed in their #INCLUDE statements. For example, the LMHOSTS files on the computers in subnetwork A could include the LMHOSTS files of the computers on subnetwork B. When a change occurs in subnetwork B, the network administrator changes the LMHOSTS file of the computers on subnetwork B, and the LMHOSTS files on subnetwork A could remain the same. Theoretically, each LMHOSTS file on a subnetwork could contain only one address-to-NetBIOS name mapping and #INCLUDE statements that list the location of the LMHOSTS files for all other computers on the network, whether remote or local. A change or addition to this file would then be propagated to all other computers listed in the #INCLUDE statement. Practically, however, the number of #INCLUDE statements is limited to 100 entries.

DNS

DNS is described in RFCs 1034 and 1035. One of the most sophisticated methods of name resolution, DNS resolves host names and is essential for connecting to the Internet. Used extensively in both NT and Unix networks, this name resolution method is becoming more popular for networks of all sizes and is an integral part of Windows 2000 Server’s Active Directory (Active Directory can’t function without it).

Although DNS has been around for a long time, it has been hampered by the fact that, like HOSTS and LMHOSTS files, it is a static name resolution service. Any changes or additions to the network must be manually entered into the DNS database. However, this isn’t quite as painful as changing HOSTS and LMHOSTS files because only the centrally located database must be changed. Also, by integrating DNS with the Microsoft proprietary dynamic name resolution system, WINS, DNS under NT 4.0 can be made to behave as if it were dynamic. (DNS queries that can’t be resolved can be sent to WINS for resolution. See “WINS” below and “Enabling WINS Lookup” later in this chapter.)

Under Windows 2000 Server, however, a new form of dynamic DNS is used that automatically registers dynamic updates in the DNS database without using WINS. See “Dynamic DNS: Theory” and “Differences Between NT 4.0 and Windows 2000 Server” later in this chapter.

WINS

We cover WINS in depth in Chapter 9. Briefly, as we mention above, WINS is Microsoft’s proprietary dynamic name resolution system. It is basically a database program that keeps track of which NetBIOS names map to which IP addresses. WINS can provide the name and IP address of any computer on a network that has registered itself with the WINS server.

Windows 2000 Server implements a fully dynamic DNS that will eventually render WINS name resolution obsolete. The one drawback, however, is that any NetBIOS-only applications will have to be replaced because they will no longer run on a TCP/IP-only network. In the interim, therefore, WINS is still available, able to be fully integrated with DNS, and still an important service for most networks. It will be a long time before WINS is entirely out of the picture.

DYNAMIC DNS

Dynamic DNS is not a new term. The integration of dynamic WINS NetBIOS/IP name resolution with static DNS has often been called Dynamic DNS. Third-party products have also claimed to make DNS dynamic.

Dynamic DNS is described in RFCs 2136 and 2137. Because Windows 2000 Server is, at the time of this writing, still in the beta stage, it is difficult to say how much of these RFCs will be implemented. However, because RFC 2136 has been adopted as an Internet protocol standard, it is reasonable to expect that Windows 2000 Server’s implementation of dynamic DNS will be similar.

Dynamic DNS involves two classes of zone servers: master and slave. (For the moment, think of zones as domains, although there is a subtle distinction, as you will see in “DNS Zones” later in the chapter.) Examples of possible slaves include domain controllers, secondary zone servers, and WINS and DHCP servers.

Dynamic DNS uses a method by which slave servers send updates of their zone files to a primary master zone server. As in static DNS, only the master zone server actually implements the update, but by using an update message, slaves are permitted to request an update of the master zone files. Whether the update is acknowledged, granted, or returned with an error depends on the message sent and on the options selected for the primary zone server.

Page: 1, 2, 3, 4

ADS BY GOOGLE