SOME OF THE MAIN TOPICS IN THIS CHAPTER ARE
Hardware Versus Protocol Addresses 525
Installing and Configuring WINS on Windows 2000/2003 Servers 534
Installing DNS on a Windows Server 552
Network Information Service 553
Computers use hardware addresses when exchanging data on the local subnet. These addresses are burned into the network adapter and are often referred to as MAC (Media Access Control) addresses. MAC addresses produce a flat address space, so network protocols, such as IP, are typically used to create a hierarchical address space. However, for humans, both MAC and IP addresses (or IPX/SPX addresses, for that matter) are difficult to remember. Names are convenient for use by humans who have to operate computers. So, besides identifying a computer or network device using a protocol address, it’s also important to be able to give a name to a computer, a network device, or a service, and then have that name resolved to the address so that data communications can take place on the network.
Understanding how name resolution works on your network will better prepare you to troubleshoot the problems users encounter when trying to locate resources.
This chapter deals with standard name resolution techniques ranging from the simple LMHOSTS
files to the Windows Internet Name Service (WINS) for NetBIOS names and HOSTS
files and the Domain Name System (DNS) service for IP names. For most networks, such as those that have Unix, Linux, or Windows computers, the name resolution methods described in this chapter will suffice. However, Windows 2000, Windows XP, or Windows Server 2003—when deployed using the Active Directory—adds a whole new dimension to name resolution. The Active Directory stores objects that can represent everything from a user account to a resource on the network, such as a computer or a printer. If you employ Windows 2000 or 2003 Servers in your network, you might find Chapter 30, “Using the Active Directory,” to be an important resource.
In a similar fashion, Novell Directory Services—NDS, now called the eDirectory—is a directory-based solution that maintains information about and provides access to every resource on the network.
Active Directory and eDirectory can be used to quickly locate resources on the network. They do, however, take the concept of name resolution farther down the road in that you can locate a resource using its name as well as by specifying attributes of the resource you need to use. For example, if you don’t know the name of a printer, directory servers enable you to specify search criteria to locate it (or any resource). In the case of a printer, you can specify that it be a color printer, a printer stationed at a particular location, or even such criteria as whether it prints in duplex mode or has three-hole paper installed.
Another important factor to consider when using a directory service is that it is not a replacement for the name resolution techniques described in this chapter. This is easy to understand when you consider that that, in a Windows Server environment, a client computer uses a DNS entry to locate a domain controller so that it can authenticate itself to the network before it can even begin to use the Active Directory.
For Unix/Linux systems, the upgrade path from the older HOSTS
file was Sun’s Network Information System (NIS), which was formerly called Yellow Pages, until trademark issues forced a name change. Later versions of NDS, which provide additional security and other facilities, are now called NFS+.
You’ll find both NIS commands as well as commands that start with the letters yp
on some Unix systems. Today there is a growing movement to move authentication and other information to an LDAP-based directory server. A number of LDAP-enabled directory servers can be used with different operating system platforms, and a quick search on the Internet can reveal a lot of information. In addition, there’s an open source version of an LDAP server that you can review at http://www.openldap.org
. For a basic overview of LDAP, see Appendix D, “The Lightweight Directory Access Protocol.”
When working in a multiprotocol environment, there are several ways in which you can create a single namespace using an LDAP-enabled directory to provide a single directory service for Windows, Unix, Linux, and NetWare clients. You’ll find a discussion of these topics and the utilities that can help you get there in Part XI, “Migration and Integration,” later in this book.
When communicating on the same network segment, a computer can communicate directly by sending directed Address Resolution Protocols (ARP) packets to another computer using the network card’s unique MAC address. In TCP/IP networks, the ARP is used in a local broadcast domain to determine the hardware address of another computer by sending out a broadcast packet that contains the computer’s IP address. When a computer recognizes an ARP packet that has its IP address, it responds to the ARP request with another packet that tells the original computer what the destination computer’s MAC address is. For more information about hardware addresses, which are stored in the local ARP cache and ARP, see Chapter 24, “Overview of the TCP/IP Protocol Suite.”
The TCP/IP protocol is pretty much the standard today for local area networks. NetBIOS has been adapted to run over IP, and beginning with NetWare 5, IP is now the preferred protocol used in NetWare LANs. To begin, however, let’s look at the older NetBIOS namespace and NetBEUI protocol that were used on Microsoft’s first offerings in the LAN environment.
The NetBIOS and NetBEUI protocols are described in “NetBIOS and NetBEUI,” which is on the upgradingandrepairingpcs.com
Web site. Although the original specifications were sufficient for use on only very small LANs (fewer than 200 nodes), NetBIOS has been a mainstay in most Microsoft network products. Until Windows 2000, NetBIOS names were integral to the Windows operating systems’ management functions. For example, domain names and host names are made up of NetBIOS names. The Server Message Block (SMB) protocol that’s used for resource access and administrative duties in LAN Manager and the Windows operating systems’ networking software modules are based on NetBIOS names.
The Server Message Block protocol is now called the Common Internet File System (CIFS), which is discussed later in this chapter. To provide for interoperability with Windows networks, many vendors created SMB/CIFS products. The Unix and Linux communities have ventured into this territory with Samba. Samba is an SMB/CIFS client/server system that you can install on Unix and Linux clients or servers and use to access typical Windows NetBIOS-based resources. You can read up on the latest version of Samba or download the software using the URL http://www.samba.org
.
In the %systemroot%SYSTEM32DRIVERSETC
directory on Windows NT 4.0, Windows 2000, XP, and Windows Server 2003 computers is a file named LMHOSTS.SAM
. For Windows 95 and Windows 98 clients, this file is found in the WINDOWS
directory. It’s used to map NetBIOS names to IP addresses. The .SAM
filename extension indicates that this is a sample file. If you’re going to use the file, you have to copy it or rename it LMHOSTS
with no file extension. Because it’s always a good idea to keep the original copy in case things become confused along the line, making a copy is a good choice.
To rename the file from the command line, set your working directory to the directory in which the file resides and enter
ren lmhosts.sam lmhosts
To copy the file (and preserve the original sample file), enter
copy lmhosts.sam lmhosts
The Windows files are basically the same for all versions of Windows, except for a few of the comment lines. The following is the version you’ll find in Windows Server 2003:
# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample LMHOSTS file used by the Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to computernames
# (NetBIOS) names. Each entry should be kept on an individual line.
# The IP address should be placed in the first column followed by the
# corresponding computername. The address and the computername
# should be separated by at least one space or tab. The "#" character
# is generally used to denote the start of a comment (see the exceptions
# below).
#
# This file is compatible with Microsoft LAN Manager 2.x TCP/IP lmhosts
# files and offers the following extensions:
#
# #PRE
# #DOM:<domain>
# #INCLUDE <filename>
# #BEGIN_ALTERNATE
# #END_ALTERNATE
#