Lesson 1:TCPIP Services

The core protocols that TCP/IP uses to provide communication between computers—the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the User Datagram Protocol (UDP)—rely on several other services to perform their functions. Some of these services take the form of independent protocols, such as the Address Resolution Protocol (ARP), which runs on every TCP/IP computer and enables IP to discover the hardware address of a computer using a particular IP address. Other services, such as the Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS), are both protocols and applications that run on their own servers.

---

After this lesson, you will be able to

• Explain how DHCP assigns TCP/IP configuration settings to workstations
• Understand the history of name resolution on the Internet
• Understand the functions of DNS and the Windows Internet Naming Service (WINS)

Estimated lesson time: 60 minutes

---

DHCP

In Chapter 6, "Network Layer Protocols," and Chapter 8, "TCP/IP Fundamentals," you learned about the advantages of TCP/IP's self-contained addressing system and about the nature of IP addresses themselves. Although there are many advantages of IP addressing, there are several significant problems with it, including that every computer on the network must have a unique IP address. This requirement complicates the process of configuring the TCP/IP client. The administrators of a TCP/IP network must be sure that every computer is configured properly, which means keeping track of the IP address assignments so that no duplication occurs. On a small network, configuring the individual TCP/IP workstations and keeping track of their IP addresses is relatively painless, but on a large corporate internetwork, it can be a monumental task.

DHCP Origins

Over the years, the developers of the TCP/IP protocols have worked out several solutions that address the problem of configuring the TCP/IP settings for large numbers of workstations. The first of these was the Reverse Address Resolution Protocol (RARP), which was designed for diskless workstations that had no means of permanently storing their TCP/IP settings. RARP is essentially the opposite of ARP. Whereas ARP broadcasts an IP address in an effort to discover its equivalent hardware address, RARP broadcasts the hardware address, as shown in Figure 10.1. An RARP server then responds by transmitting the IP address assigned to that client computer. RARP was suitable for use with diskless workstations on early TCP/IP networks, but it isn't sufficient for today's needs because it supplies the computer with only an IP address. It provides none of the other settings needed by a typical workstation today, such as a subnet mask and a default gateway.

Figure 10.1  A workstation that uses RARP receives an IP address from a RARP server in response to a broadcast message containing the client's hardware address

For more information about ARP, including its message format, which is the same as that used by RARP, see Lesson 1: TCP/IP Protocols, in Chapter 8, "TCP/IP Fundamentals."

The next attempt at an automatic TCP/IP configuration mechanism was called the Bootstrap Protocol (BOOTP). BOOTP does more than RARP, which is why it is still used today, whereas RARP is not. BOOTP enables a TCP/IP workstation to retrieve settings for all of the configuration parameters it needs to run, including an IP address, subnet mask, default gateway, and DNS server addresses. A workstation can also download an executable boot file from a BOOTP server, using the Trivial File Transfer Protocol (TFTP), which makes it clear that BOOTP, like RARP, was designed for diskless workstations. The drawback of BOOTP is that although it is capable of performing all the TCP/IP client communication tasks required by today's computers, an administrator must still specify the settings for each workstation on the BOOTP server. There is no mechanism for automatically assigning a unique IP address to each computer, nor is there any means of preventing two computers from receiving the same IP address due to administrator error.

Microsoft developed DHCP for the express purpose of addressing the shortcomings in RARP and BOOTP. DHCP is based on BOOTP to a great extent, but instead of simply feeding predetermined configuration parameters to TCP/IP clients, DHCP can dynamically allocate IP addresses from a pool and reclaim them when they are no longer in use. This prevents workstations from being assigned duplicate IP addresses and enables administrators to move computers around between subnets without manually reconfiguring them. In addition, DHCP can deliver a wide range of configuration parameters to TCP/IP clients, including platform-specific parameters added by third-party developers.

DHCP Architecture

DHCP consists of three components: a client, a server, and the protocol that they use to communicate with each other. Most TCP/IP implementations these days have DHCP integrated into the networking client, even if the operating system doesn't specifically refer to it as such. On a Microsoft Windows 2000 system, for example, in the Internet Protocol (TCP/IP) Properties dialog box, when you select Obtain An IP Address Automatically, you are actually activating the DHCP client. The DHCP server is an application that runs on a computer and exists to service requests from DHCP clients. The Windows 2000 Server and Microsoft Windows NT Server operating systems both include the DHCP server application, but there are many other implementations available for other platforms as well. DHCP is widely used on UNIX, Novell NetWare, and Microsoft networks. Any DHCP client can retrieve configuration settings from a DHCP server running on any platform. Despite having been developed largely by Microsoft, DHCP is based on public BOOTP standards and is published as an open TCP/IP standard.

The basic components of DHCP are defined in Request for Comments (RFC) 2131, published by the Internet Engineering Task Force (IETF). RFC 2132 defines additional DHCP options and vendor extensions that can supply other types of information to client computers.

The core function of DHCP is to assign IP addresses. This is the most complicated part of the service, because the IP address must be unique for each client computer. The DHCP standard defines three types of IP address allocation, as follows:

• Manual allocation.  An administrator assigns a specific IP address to a computer in the DHCP server and the server provides that address to the computer when it is requested.
• Automatic allocation.  The DHCP server supplies clients with IP addresses taken from a common pool of addresses, and the clients retain the assigned addresses permanently.
• Dynamic allocation.  The DHCP server supplies IP addresses to clients from a pool on a leased basis. The client must periodically renew the lease or the address returns to the pool for reallocation.

Manual allocation is the functional equivalent of BOOTP address assignment. This option saves the least administrative labor, but it is necessary for systems that require permanently assigned IP addresses, such as Internet servers that have DNS names associated with specific addresses. Administrators could conceivably configure the TCP/IP clients of these computers directly, but using the DHCP server for the assignment prevents IP addresses from being accidentally duplicated.

Automatic allocation is a fitting solution for networks on which administrators rarely move workstations between subnets. Assigning IP addresses from a pool (called a scope) eliminates the need to furnish a specific address for each computer and prevents address duplication. Permanently assigning those addresses minimizes the network traffic generated by DHCP client/server communications.

Once the server is configured, dynamic allocation completely automates the TCP/IP client configuration process, enabling administrators to add, remove, and relocate computers as needed. When a computer boots, the server leases an address to the computer for a given period of time, renews the lease if the computer remains active, reclaims the address when it is no longer in use, and returns the address to the pool.

DHCP Message Format

Communications between DHCP clients and servers use a single message format, which is illustrated in Figure 10.2. All DHCP messages are carried within UDP datagrams, using the well-known port numbers 67 at the server and 68 at the client, as established by the Internet Assigned Numbers Authority (IANA).

Figure 10.2  The DHCP message format

The functions of the fields in the DHCP message are as follows:

• op (1 byte).  Specifies whether the message originated at a client or a server
• htype (1 byte).  Specifies the type of hardware address in the chaddr field
• hlen (1 byte).  Specifies the length of the hardware address in the chaddr field, in bytes
• hops (1 byte).  Specifies the number of routers in the path between the client and the server
• xid (4 bytes).  Contains a transaction identifier used to associate requests and replies
• secs (2 bytes).  Specifies the elapsed time (in seconds) since the beginning of an address allocation or lease renewal process
• flags (2 bytes).  Indicates whether or not DHCP servers and relay agents should use broadcast transmissions to communicate with a client instead of unicast transmissions
• ciaddr (4 bytes).  Contains the client computer's IP address when it is in the bound, renewal, or rebinding state
• yiaddr (4 bytes).  Contains the IP address being offered to a client by a server
• siaddr (4 bytes).  Specifies the IP address of the next server in a bootstrap sequence; used only when the DHCP server supplies an executable boot file to a diskless workstation
• giaddr (4 bytes).  Contains the IP address of a DHCP relay agent located on a different network, when necessary
• chaddr (16 bytes).  Contains the hardware address of the client system, using the type and length specified in the htype and hlen fields
• sname (64 bytes).  Contains either the host name of the DHCP server or overflow data from the options field
• file (128 bytes).  Contains the name and path to an executable boot file for diskless workstations
• options (variable).  Contains a series of DHCP options, which specify the configuration parameters for the client computer

The options field is where the DHCP message carries all of the TCP/IP parameters assigned to a client, except for the IP address. Each option consists of three subfields, as shown in Figure 10.3.

Figure 10.3  The DHCP option format

The functions of the option subfields are as follows:

• Code (1 byte).  Specifies the function of the option
• Length (1 byte).  Specifies the length of the data field
• Data (variable).  Contains information specific to the option type

Although it sounds like a contradiction in terms, there is one DHCP option that is required. This is the DHCP Message Type option, which contains a code that specifies the function of each message. There are eight possible values for this option, as follows:

• 1—DHCPDISCOVER.  Used by clients to request configuration parameters from a DHCP server
• 2—DHCPOFFER.  Used by servers to offer IP addresses to requesting clients
• 3—DHCPREQUEST.  Used by clients to accept or renew an IP address assignment
• 4—DHCPDECLINE.  Used by clients to reject an offered IP address
• 5—DHCPACK.  Used by servers to acknowledge a client's acceptance of an offered IP address
• 6—DHCPNAK.  Used by servers to reject a client's acceptance of an offered IP address
• 7—DHCPRELEASE.  Used by clients to terminate an IP address lease
• 8—DHCPINFORM.  Used by clients to obtain additional TCP/IP configuration parameters from a server

DHCP Communications

DHCP clients initiate communication with servers when they boot for the first time, as illustrated in Figure 10.4. The client generates a series of DHCPDISCOVER messages, which it transmits as broadcasts. At this point, the client has no IP address, and is said to be in the init state. Like all broadcasts, these transmissions are limited to the client's local network, but administrators can install a DHCP Relay Agent service on a computer on the local area network (LAN), which relays the messages to DHCP servers on other networks. This enables a single DHCP server to service clients on multiple LANs.

When a DHCP server receives a DHCPDISCOVER message from a client, it generates a DHCPOFFER message containing an IP address and whatever other optional parameters the server is configured to supply. In most cases, the server transmits this as a unicast message directly to the client. Because the client broadcasts its DHCPDISCOVER messages, it may receive DHCPOFFER responses from multiple servers. After a specified period of time, the client stops its broadcasting and accepts one of the offered IP addresses. To signal its acceptance, the client generates a DHCPREQUEST message containing the address of the server from which it is accepting the offer along with the offered IP address. Because the client has not yet configured itself with the offered parameters, it transmits the DHCPREQUEST message as a broadcast. This broadcast notifies the server that the client is accepting the offered address and also notifies the other servers on the network that the client is rejecting their offers.

Figure 10.4  DHCP client/server communications

On receipt of the DHCPREQUEST message, the server commits the offered IP address and other settings to its database using a combination of the client's hardware address and the offered IP address as a unique identifier for the assignment. This is known as the lease identification cookie. To conclude its part of the transaction, the server sends a DHCPACK message to the client, acknowledging the completion of the process. If the server cannot complete the assignment (because it has already assigned the offered IP address to another system, for example), it transmits a DHCPNAK message to the client and the whole process begins again.

As a final test, the client performs an ARP test to ensure that no other system on the network is using the assigned IP address. If no response is received, the DHCP transaction is completed and the client enters what is known as the bound state. If another system does respond, the client can't use the IP address and transmits a DHCPDECLINE message to the server, nullifying the transaction. The client can then reissue a series of DHCPDISCOVER messages, restarting the whole process.

DHCP Leasing

The process by which a DHCP server assigns configuration parameters to a client is the same whether the server uses manual, automatic, or dynamic allocation. With manual and automatic allocation, this process is the end of the DHCP client/server communications. The client retains the settings assigned to it by the server until someone explicitly changes them or forces a reassignment. However, when the server dynamically allocates settings, the client leases its IP address for a certain period of time (configured at the server) and must renew the lease to continue using it.

The length of an IP address lease is typically measured in days and is generally based on whether computers are frequently moved around the network or whether IP addresses are in short supply. Shorter leases generate more network traffic but enable servers to reclaim unused addresses faster. For a relatively stable network, longer leases reduce the amount of traffic that DHCP generates.

The lease renewal process, illustrated in Figure 10.5, begins when a bound client reaches what is known as the renewal time value, or T1 value, of its lease. By default, the renewal time value is 50 percent of the lease period. When a client reaches this point, it enters the renewing state and begins generating DHCPREQUEST messages. The client transmits the messages to the server that holds the lease as unicasts, unlike the broadcast DHCPREQUEST messages the client generates while in the init state. If the server is available to receive the message, it responds with either a DHCPACK message, which renews the lease and restarts the lease time clock, or a DHCPNAK message, which terminates the lease and forces the client to begin the address assignment process again from the beginning.

Figure 10.5  The DHCP lease renewal process

If the server does not respond to the DHCPREQUEST unicast message, the client continues to send them until it reaches the rebinding time value or T2 value, which defaults to 87.5 percent of the lease period. At this point, the client enters the rebinding state and begins transmitting DHCPREQUEST messages as broadcasts, soliciting an address assignment from any DHCP server on the network. Again, a server can respond with either a DHCPACK or DHCPNAK message. If the lease time expires with no response from any DHCP server, the client's IP address is released and all of its TCP/IP communication ceases, except for the transmission of DHCPDISCOVER broadcasts.

Releasing an IP Address

It is also possible for a client to terminate an IP address lease at any time by transmitting a DHCPRELEASE message containing the lease identification cookie to the server. On a Microsoft Windows system, for example, you can do this manually, using the IPCONFIG.EXE utility in Windows 2000 and Windows NT or the WINIPCFG.EXE utility in Microsoft Windows Me, Microsoft Windows 98, or Microsoft Windows 95. For more information about these utilities, see Lesson 2: TCP/IP Utilities, later in this chapter.

Run the DHCP video located in the Demos folder on the CD-ROM accompanying this book for a demonstration of DHCP address assignment.

Exercise 1: DHCP Message Types

1. Place the following DHCP message types in the order in which a successful IP address assignment procedure uses them.
   1. DHCPACK
   2. DHCPOFFER
   3. DHCPREQUEST
   4. DHCPDISCOVER
2. Place the following DHCP message types in the proper order for an unsuccessful attempt to renew an IP address lease.
   1. DHCPDISCOVER
   2. DHCPREQUEST (broadcast)
   3. DHCPREQUEST (unicast)
   4. DHCPNAK

Host Files

IP addresses may be an excellent way for computers to recognize and communicate with each other, but they are not exactly user-friendly. Imagine having to remember the IP address for every site that you visit while surfing the Web or for every computer on the local network that has drives or printers you want to access. To make TCP/IP more user-friendly, its developers created host names, which enable administrators to assign friendly names to the computers on a network and resolve them into IP addresses as needed.

A host name is simply a name used to represent a computer. The names of the hosts on a network are stored in a text file called HOSTS on each computer. The HOSTS file also contains the IP address of the computer associated with each of those names. To communicate with another computer on the network by specifying its host name, your computer must first resolve that name into its IP address by looking it up in the HOSTS file. Name resolution is the process of converting a name into its equivalent IP address. The name resolution process is essential, because an IP datagram must use an IP address, and not a name, to identify its destination.

Every computer must have its own HOSTS file, which is why this name resolution method is not widely used today. In the early days of the Internet, when the entire network consisted of a few dozen computers, administrators regularly downloaded updated HOSTS files containing entries for all of the computers on the Internet. Today a HOSTS file for the entire Internet would be enormous, even if you could compile one, and requiring every computer to download it would bring the entire network to its knees. However, if there are computers on the network that you visit frequently, you can put them in a HOSTS file on your computer to bypass the more elaborate name resolution methods used today.

DNS

When the Internet outgrew the HOSTS file, it also outgrew the flat namespace the file used. There were too many systems to assign each a unique single name. To address these problems, the TCP/IP developers created the Domain Name System (DNS), which enables administrators to assign hierarchical names to the computers on a network and resolve them into IP addresses as needed. The DNS is defined in two primary IETF documents: RFC 1034, "Domain Names: Concepts and Facilities," and RFC 1035, "Domain Names: Implementation and Specification." There are many additional RFCs that provide updates and augmentations to the DNS.

Whenever you use a DNS name to refer to a TCP/IP computer, such as when you type www.microsoft.com into your Web browser, your workstation performs a name resolution process before it sends any traffic to the destination server. If you look quickly, you might see your browser display a status message for a fraction of a second, indicating that it is resolving the name. To perform a name resolution, the client computer transmits a message containing the name to a DNS server, the address of which is specified as part of its TCP/IP client configuration. The DNS client implementation found in every computer running TCP/IP is called a resolver. The DNS server determines the IP address associated with the name requested by the resolver and returns it to the client. The client can then send its original message to the desired destination using its IP address.

Understanding how your local DNS server obtains the IP addresses for the names sent to it by your computer can be complicated and requires you to understand how DNS names are structured and assigned. The primary element of the DNS is its hierarchical namespace, which identifies computers using names composed of three or more words, separated by periods. The DNS name of a computer consists of a host name and a domain name. The domain name, which consists of two or more words, identifies a network or an organization running a network, and the host name identifies a specific computer on that network or in that organization. In the name www.microsoft.com, for example, www is the name of a particular host in the domain microsoft.com.

Domain names on the Internet must be registered with an organization that is responsible for ensuring there is no duplication of names. DNS names are read from right to left, with the word furthest to the right representing the top of the domain hierarchy. Therefore, the com in www.microsoft.com is known as a top-level domain. The original DNS standards defined eight top-level domains: com, edu, gov, mil, net, org, int, and arpa. All of these top-level domains are intended to be used for computers belonging to different types of organizations, with edu being for educational institutions, mil for the military, and so on. The term arpa is a special case used for reverse—that is, address-to-name—mapping.

Today, in addition to these eight, there are numerous additional top-level domains that represent various countries around the world. These international top-level domain names have only two letters, and are often abbreviations for the country name in its own language. For example, de is the top-level domain for Germany (Deutschland) and fr for France. There are also other, special-purpose, top-level domains that have only recently been introduced, but these have yet to have a major impact in the business world.

By contacting a registrar who is responsible for one or more top-level domains, any individual or organization can register a second-level domain within that top-level domain for a nominal fee. Top-level domains like edu, gov, and mil are restricted to the educational, government, and military organizations they describe, respectively, but the registrars of the com, org, and net top-level domains allow anyone to register names in those domains, as do many of the international domain registrars.

Once an individual or organization has registered a domain name, the owner is free to create as many hosts or subdomains in that domain as they wish. The word furthest to the left in a full DNS name is the host, and any names to the right of the host identify the domain. Thus, as shown in Figure 10.6, the owner of the microsoft.com domain can create any number of subdomains, such as msn.microsoft.com, and any number of hosts in each of those subdomains, such as www.msn.microsoft.com. This two-tiered administrative arrangement is the same as that for IP addresses. An administrative body is responsible for registering the network addresses assigned to various organizations, and the administrators of the organizations themselves then create the host address assignments.

Figure 10.6  A DNS name can include several domain levels, or as few as two, plus a host name

---

Domain Name Registration and Big Business

With the increasing commercialization of the Internet, domain name registration has become a lucrative business and a point of legal contention as well. In some cases, popular domain names are being sold for millions of dollars, either by failed companies that no longer need them or by forward-thinking entrepreneurs who registered them before the Internet boom. In other cases, large corporations have filed legal suits to have certain domain names stripped from their legal registrants simply because they have the same name as the corporation. Creative domain registration is also being used for unscrupulous business practices. For example, the owners of a corporation might register domains using the names of its competitors, so that potential customers are directed to the corporation's Web site when they look for a Web site using a competitor's name. At this time, the courts are still mulling over the legal issues pertaining to Internet rights.

---

Although they use the same basic administrative model, IP address registrations and domain name registrations are completely separate. You can have computers on many different IP networks using the same domain name, or you can have multiple domain names used by computers on the same network.

Splitting the administrative chores between a central body and the individual registrant is part of what makes it possible to keep the DNS namespace up to date. There are thousands of domains on the Internet today, and millions of hosts in those domains. To create a central registry for all of this information would require enormous manpower and technology resources. Instead, the responsibility for maintaining the DNS namespace is distributed among servers and administrators all over the Internet. It's remarkable that a system designed when the Internet wasn't a hundredth of its current size still functions well, even though it has grown far beyond the wildest dreams of its conceivers.

DNS Communications

The relationship of the various domain levels becomes apparent when you examine the process by which DNS servers resolve names into IP addresses. Because of the distributed nature of the DNS namespace, there is no single server that contains a complete listing of all the domains on the Internet and all of the hosts on those domains. Therefore, when a client system sends a name to its DNS server for resolution, the server must have some means of locating the information it needs. The server does this by parsing the DNS name it receives from the client and working with one domain level at a time.

Every DNS server has the IP addresses of several root-name servers. These servers are responsible for maintaining a list of the top-level domains and the IP addresses of the DNS servers that are authoritative for those domains. An authoritative server is the computer that is the final source of information about a particular domain. Usually this is a server run by the administrators of the domain, on which they make changes when they modify their network configuration. The root-name servers are, in fact, the authoritative servers for most of the original eight top-level domains, but they also contain the addresses of the authoritative servers for the many international domains. These servers handle only a small part of the name resolution process, but they still process hundreds of requests per second.

A DNS server trying to resolve a name sends a message to one of the root-name servers requesting the address of the authoritative server for the top-level domain in the name (see Figure 10.7). Thus, a server trying to resolve the name www.microsoft.com sends a request to a root-name server, asking for the address of the authoritative server for the com domain. Because that server is authoritative for the com domain, it skips a step and supplies the address for the microsoft.com domain's authoritative server. Otherwise, the root-name server would respond with the address of the top-level domain server, and the original server would send a new request to the top-level domain server for the address of the second-level domain's authoritative server. Once the original server knows the address of the microsoft.com domain's authoritative server, it generates a request for the IP address of the host www. The microsoft.com server responds with the requested IP address, and the original server passes that address to the client.

In this way, any DNS server on the Internet can locate the IP address for a computer in any domain. However, in many cases, the servers can bypass part of this process because they can usually cache information about the names they resolve. For a popular DNS name like www.microsoft.com, for example, it is very possible that the client's DNS server already has the required IP address in its cache and can furnish it directly to the client without communicating with other servers.

Run the DNSNameResolution video located in the Demos folder on the CD-ROM accompanying this book for a demonstration of the DNS name resolution process.

Figure 10.7  The DNS name resolution process

Reverse Name Resolution

DNS is designed to resolve names into IP addresses, but there are cases in which TCP/IP computers require the opposite service, the conversion of an IP address into a name. Because the DNS namespace is distributed based on the domain names, however, this task is almost impossible when using the system's standard capabilities. Finding a specific IP address in the namespace would require a search of all of the authoritative DNS servers on the Internet, which obviously is not practical.

To address this problem, the DNS name space includes a special domain called in-addr.arpa, which reverses the name/address relationship by containing domains that are named using IP addresses. In other words, in-addr is a second-level domain beneath arpa, and beneath in-addr there are 256 possible third-level domains, which are named using the numbers 0 to 255. These third-level domains represent the first byte of an IP address. Each of the third-level domains has 256 possible fourth-level domains, representing the second byte of an IP address. The fifth- and sixth-level domains work in the same way, enabling you to search in the DNS namespace for any possible IP address. For example, the IP address 192.168.2.6 would be found in the domain name 6.2.168.192.in-addr.arpa. This domain would contain a resource record that specifies the DNS name of the computer using this IP address. The bytes of the IP address are reversed in the domain name because, in an IP address, the most significant identifier is first, and in a domain name, the top-level domain comes last.

DNS Resource Records

Despite the complexity of the distributed namespace, DNS servers themselves are actually relatively simple. DNS servers store their information in units called resource records, which administrators of authoritative servers must create manually, in most cases. In response to a request from a resolver or another server, the DNS server transmits a message containing the resource record for the requested name. There are many different types of resource records, the most important of which are as follows:

• Start of Authority (SOA).  Indicates that the name server is the authoritative source for the domain
• Name Server (NS).  Identifies the DNS servers in the domain
• Address (A).  Contains a name-to-address mapping for a computer in the domain
• Canonical Name (CNAME).  Used to create an alternative (or alias) name for a computer already represented by an Address record
• Pointer (PTR).  Contains an address-to-name mapping in in-addr.arpa for a computer in the domain
• Mail Exchange (MX).  Identifies a computer that is responsible for processing e-mail traffic addressed to the domain

The need to manually create resource records is one of the long-standing shortcomings of DNS. Now that Windows 2000 relies heavily on DNS for its Active Directory service, the IETF has published additional documents that define new server features, such as RFC 2136, "Dynamic Updates in the Domain Name System," which specifies a method for automatically creating and updating DNS resource records.

WINS

Windows Internet Naming Service (WINS) is similar to DNS in that it is designed to resolve computer names into IP addresses. However, WINS is designed specifically for Windows networks and resolves the NetBIOS names used by Windows systems, rather than the DNS names used on the Internet. The NetBIOS namespace that Windows uses to provide friendly names for computers is not hierarchical like that of DNS, but the problem of using TCP/IP with these names is the same. A computer must resolve the name of the computer it wants to communicate with into an IP address before it can send IP datagrams to it.

WINS is included with the Windows NT Server and Windows 2000 Server operating systems. However, the Active Directory technology in Windows 2000 uses DNS instead of NetBIOS names, so the WINS server is included only to service downlevel clients, that is, workstations running earlier versions of Windows.

Windows has several ways of resolving NetBIOS names into IP addresses, so WINS is not an essential part of a Windows network. Without WINS, a computer resolves NetBIOS names either by looking them up in a text file similar to HOSTS, called LMHOSTS, or by transmitting broadcast messages containing the desired name on the LAN, and then waiting for the computer using that name to respond with its IP address. WINS is designed to increase the efficiency of the network by reducing the amount of broadcast traffic. Instead of broadcasting a request, a WINS client transmits a request to its designated WINS server as a unicast message, and the server responds with the IP address associated with the requested name.

For more information about NetBIOS names, see Lesson 3: NetBEUI, in Chapter 6, "Network Layer Protocols."

Unlike DNS, which requires administrators to create resource records manually, WINS automatically registers clients as they boot, then adds their names and IP addresses to its database. WINS is also designed for use on large internetworks. You can run multiple WINS servers to provide fault tolerance and service thousands of clients. WINS servers can also communicate with each other to replicate their database information, enabling you to maintain a composite picture of the entire network on all of your servers.

Lesson Review

1. What does the first word in a full DNS name identify?
   1. The top-level domain
   2. The second-level domain
   3. The DNS server
   4. The host
2. What happens to a DHCP client when its attempts to renew its IP address lease fail and the lease expires?
3. Which of the following message types is not used during the DHCP lease assignment process?
   1. DHCPDISCOVER
   2. DHCPRELEASE
   3. DHCPOFFER
   4. DHCPREQUEST
4. What is the DNS resource record type that contains the basic name-to-address mapping used for name resolution?
   1. Address
   2. Pointer
   3. Canonical Name
   4. Start of Authority
5. What is the name of the DNS domain that contains address-to-name mappings?
6. Name one method other than WINS that computers running Windows can use to resolve NetBIOS names into IP addresses.
7. What is the name of the time during the lease renewal process when a DHCP client begins broadcasting DHCPREQUEST messages?
   1. Lease identification cookie
   2. Rebinding time value
   3. Renewal time value
   4. Init value
8. What is the function of a WINS server?
   1. To convert IP addresses into hardware addresses
   2. To convert host names into IP addresses
   3. To convert IP addresses into host names
   4. To convert NetBIOS names into IP addresses

Lesson Summary

• DHCP is a combination of a client, a server, and a protocol that can automatically configure the TCP/IP clients on computers all over the network.
• DHCP is capable of leasing IP addresses from a common pool to client computers, reclaiming them when they are no longer in use, and then returning them to the pool for reassignment.
• DNS enables users to identify computers on a network using friendly names instead of IP addresses. DNS servers resolve the names into the IP addresses that computers need to communicate using TCP/IP.
• The DNS namespace is hierarchical; a computer's DNS name consists of a host name followed by two or more domain names, separated by periods.
• DNS servers store information in the form of resource records, which contain name-to-address mappings and other information.
• WINS is a Microsoft Windows service that converts NetBIOS names into IP addresses.