Previous Page TOC Next Page



12

DHCP and WINS

When many people hear the acronyms DHCP and WINS, they immediately think of Microsoft. Although Microsoft was the first to introduce products based on these proposed Internet standards, they are by no means proprietary, nor are their uses completely limited to the Windows environments. DNS on the other hand, has long held a place of reverence in the world of TCP/IP.

DHCP and WINS are closely related services in the Microsoft TCP/IP networking world. Therefore, we discuss them first. Then we discuss the DNS server service in Windows NT Server 4.0 and how it is integrated with the WINS server to provide dynamic DNS.

The Windows Internet Naming Service (WINS) and Dynamic Host Configuration Protocol (DHCP) are client/server services, which means that there is at least one server-based service that provides information to clients on the network. Microsoft introduced its first WINS and DHCP servers in 1994 with Windows NT Server 3.5. Of course, both Windows NT Server and NT Workstation are also capable of being WINS and DHCP clients. Windows 95, Windows for Workgroups 3.11 with the Microsoft 32-bit TCP/IP stack (also known as Wolverine), and Windows 3.1 and DOS using the Microsoft Network Client 3.0 or LAN Manager client 2.2c can also act as DHCP/WINS clients.

So far, this list only contains Microsoft products, but there's more. The new networking stack on Macintosh computers, called OpenTransport, supports DHCP; and so do the newer TCP/IP-equipped Apple printers. In addition, many third-party TCP/IP stacks for the Windows/DOS environment, such as FTP Software's PC-TCP, support DHCP and WINS. Also many UNIX systems, such as HP’s HP/UX and SGI’s IRIX, also support DHCP.

Well, that's great, but what are WINS and DHCP for? To put it simply, DHCP is for dynamically assigning TCP/IP configuration information to network clients, and WINS is used to register and resolve names for NetBIOS clients on TCP/IP. This is very simplified, because in fact, there are many additional benefits to each service. There are also times when it is useful to install one service and not the other, as well as times when installing both services provides the best solution. In this chapter, we'll look more closely at the uses of each service, as well as deployment recommendations.


NOTE:

Microsoft first provided a DNS service with the Windows NT 3.5 Resource Kit utilities. However, it was difficult to configure, not very robust, and considered to be unstable. The DNS server that ships with NT Server 4.0 is a complete rewrite and is designed to handle large loads. It is also much easier to configure, thanks to the new graphical DNS Manager utility.


The DNS Server included with NT Server 4.0 permits your NT Server to act as a standard domain naming system (DNS) server for resolving hostnames to IP addresses. Although this is often the most-used feature of a DNS server, there are other uses, such as reverse name resolution, in which a client can request the hostname that belongs to a particular IP address, as well as mail exchange information, which provides the location of mail hosts for machines listed in the DNS domain. Windows NT Server's DNS server supports all these standard DNS services. One unique feature of the Microsoft DNS server is the integration of DNS and WINS. It does this by providing a built-in interface that enables the DNS server service to look up names in a WINS database. It can then use this information to provide name-to-IP resolution.

The goal of this chapter is to provide you with an understanding of these services so that you can properly implement the DHCP and WINS services on your network. This chapter discusses design goals, installation, configuration, and management of these services; this covers most of the administrative issues. Specific discussions regarding interoperability with existing UNIX services, tips to get the maximum mileage from these services, and some of the possible problems (gotchas) to avoid also are discussed.

The Dynamic Host Configuration Protocol

The Dynamic Host Configuration Protocol (DHCP) is not a completely new development. It is actually an extension to the BOOTP protocol (originally defined in RFC 951), which had been the standard for assigning dynamic IP addresses and remote-booting diskless workstations. Contrary to popular fiction, DHCP was not officially designed by Microsoft but rather by a group under the auspices of the Internet Engineering Task Force (IETF). Although Microsoft was a major instigating force behind DHCP, there was a general agreement in the Internet community that a sophisticated method of dynamic IP allocation was necessary. Not only would such a service simplify the initial configuration of client computers, but it would dramatically reduce the administrative overhead necessary for maintaining the IP addresses and related information, such as subnet mask and default gateways. These were but some of the thoughts that brought DHCP into existence. DHCP is fully defined in the following Requests for Comments (RFC):


NOTE:

The most interesting of these is RFC 1541, which defines the core structure and functionality of DHCP. This document can be obtained from ftp://ds.internic.net/rfc/rfc1541.txt.


Because DHCP is a client/server system, to have a fully functioning system, you must have at least one machine running the DHCP server service, and one machine with a DHCP-capable TCP/IP stack. In most scenarios, including our discussion here, the DHCP server will be a Windows NT Server with its built-in DHCP server service.


NOTE:

The number of available DHCP server services is growing fairly quickly. Many third-party TCP/IP product vendors are developing DHCP server software for Windows NT, Windows 3.x, Novell, and even UNIX systems.


This discussion of the DHCP service begins with some of the design goals of the service and then moves on to planning your installation, installing the service, and using the DHCP Manager to administer the DHCP service. Administering your DHCP service consists of creating or deleting scopes and configuring individual scope properties. A scope is nothing more than a collection of IP addresses grouped into a single component for ease of administration. A scope can include all the IP addresses in a single subnet if desired, or you can subdivide a subnet into multiple scopes. Finally, this section looks at the DHCP database management required from time to time to improve performance. You also will learn about some of the Registry keys that cannot be configured directly using the DHCP Manager.

Looking at Design Goals for the Microsoft DHCP Protocol

All companies have definite goals they must reach prior to releasing their products into the market. And Microsoft had definite goals in mind for implementing DHCP for its operating systems. The primary concern was making administration of a TCP/IP-based network easier to implement and maintain, which incidentally makes it easier for the Microsoft Product Service Support (PSS) technical support groups as well, because TCP/IP is one of the most widely implemented protocols. The TCP/IP protocol is recommended for medium to large local area networks, it is the preferred protocol to use for wide area networks, and it is required for integration with a UNIX network or the Internet.

Some of the goals for the Microsoft DHCP implementation follow:

Understanding How a DHCP Lease Works

Leases are fundamental to the entire DHCP process. Every IP address offered by a DHCP server has an associated lease period. "Lease" is an accurate term, because the DHCP server is not giving the IP address to the client, but rather is allowing the client to use the information for a specified period of time. Also, the server or the client can terminate the lease at any time.

Because one of the goals of DHCP is to provide dynamic IP addresses, there must be a method of returning these addresses to the address pool, also called a scope. The lease period is defined independently for each scope. Lease periods can be anywhere from a few minutes to a few months to forever. Different lease periods are useful in different scenarios, and there is no single lease period that fits all needs. However, I don't recommend that you use unlimited lease periods, even if you are using DHCP to statically assign your IP addresses. Make the lease periods a few months long instead.

A DHCP client computer steps through one of six transition states in the process of establishing a valid IP address for use by the client computer:


NOTE:

When a DHCP client initially tries to acquire an IP address, only four network packets are exchanged across the network, DHCP Discover, DHCP Offer, DHCP Request, and DHCP Acknowledge. Each packet is less than 400 bytes. So you can see, the network overhead associated with DHCP is relatively small.


Planning Your DHCP Installation

If you have a small network in which all your TCP/IP hosts can take advantage of DHCP, then it will be fairly easy to install the DHCP Server. But this does not mean that you can just install the DHCP Server components and forget about it; it just means that there are fewer issues to contend with in your network installation. When you begin your planning, there are two types of network configurations to consider: The first is a simple network with only one subnet; and the second, is a network with multiple subnets. The most common configuration is one with multiple subnets, and that is the focus of this discussion.

A single subnet is the easiest to work with. All the DHCP and WINS servers are located on the same subnet, so very little maintenance is required. Maintaining the LMHOSTS files is not difficult unless you have many MS-DOS or Windows 3.x clients that use the Microsoft Network Client 3.0 software. Because these computers are all on a single subnet, you can use broadcast name resolution and bypass WINS configuration and LMHOSTS file maintenance all together. But it pays, in performance, to use the same techniques that will be described for your network just as if you did have multiple segments. It also pays off if your network grows and must be divided into separate segments.

For a multiple-segmented (subnets) network, you must do some planning before installing DHCP on your server and implementing DHCP on your clients. Some issues to consider follow:

If you are planning to implement your Microsoft DHCP Server service in a mixed environment, such as with a third-party UNIX DHCP Server service, then you should be aware that not all the DHCP configuration options are supported by the Microsoft client. Specifically, the Microsoft DHCP clients only use the configuration options as specified in Table 12.1. Any other options received by the client are ignored and discarded.

Table 12.1. Microsoft DHCP client configuration options.

Number Name Data Type Description
1 Subnet Mask Subnet Address Specifies the TCP/IP subnet mask to be used by DHCP clients. NOTE:This value can be set only when you create a scope or when accessed from the DHCP Options | Scope Properties menu option.
3 Router IP Address Array Specifies a list, in order of preference, of router IP addresses to be used by the client. A locally defined gateway can override this value.
6 DNS Servers IP Address Array Specifies a list, in order of preference, for DNS name servers for the client. NOTE:A multihomed computer (a computer with more than one installed network adapter) can include only one IP address, not one IP address per adapter.
15 Domain Name String Specifies the DNS domain name the client should use for DNS hostname resolution.
44 WINS/NBNSIPAddress ArraySpecifies a list, in order of preference, of NetBIOS Name Servers (NBNS).
46 WINS/NBT Node Type Byte Specifies the node type for configurable NetBIOS clients (as defined in RFC 1001/1002). A value of 1 specifies B-node, 2 specifies P-node, 4 specifies M-node, and 8 specifies H-node. NOTE:On a multihomed computer, the node type is assigned to the computer as a whole—not to individual network adapters.
47 NetBIOS Scope ID String Specifies the scope ID for NetBIOS over TCP/IP (NBT) as defined in RFC 1001/1002. NOTE:On a multihomed computer, the scope ID is a global resource and is not allocated on a per-network adapter basis.
50 Requested Address IP Address Specifies that a client's preset IP address be used.
51 Lease Time IP Address Specifies the time, in seconds, from the initial IP address allocation to the expiration of the client lease on the IP address. NOTE:This value can be set only in the DHCP Options | Scope Properties menu option.
53 DHCP Message Type Byte Specifies the DHCP message type where the message type is 1 for DHCPDISCOVER, 2 for DHCPOFFER, 3 for DHCPREQUEST, 4 for DHCPDECLINE, 5 for DHCPACK, 6 for DHCPNAK, and 7 for DHCPRELEASE.
54 Server Identifier IP Address Used by DHCP clients to indicate which of several lease offers is being accepted by including this option in a DHCPREQUEST message with the IP address of the accepted DHCP Server.
58 Renewal (T1) Time Value Long Specifies the time, in seconds, from the initial IP address assignment to the time when the client must enter the renewal state. NOTE:This value cannot be specified manually because it is based on the lease time as set for the scope.
59 Rebinding (T2) Time Value Long Specifies the time in seconds from the initial IP address assignment to the time when the client must enter the rebinding state. NOTE:This value cannot be specified manually because it is based on the lease time as set for the scope.
61 Client ID Word Specifies the DHCP client's unique identifier.

The Microsoft DHCP client and server do not support option overlays. An option overlay is the process of using free space in the DHCP option packet to contain additional DHCP options. So if you are using a third-party DHCP Server instead of the Microsoft DHCP server, you should make sure that your important configuration options are listed first; otherwise, they might be discarded. Microsoft clients are also limited regarding the size of the DHCP packet they can properly process. This limit is 312 bytes, so you must make all the options you choose fit within this allocation. The same consideration applies if you are using the Microsoft DHCP Server to support your third-party DHCP clients: Choose your most important configuration options first. And although you can use the additional configuration options (listed in Table 12.2) to support your third-party DHCP clients, these options will not be used by your Microsoft DHCP clients.

Table 12.2. Third-party DHCP client configuration options.

Number Name Data TypeDescription
0 Pad Byte Specifies that the following data fields will be aligned on a word (16-bit) boundary.
2 Time Long Specifies the Universal Coordinate Offset Time (UCT) in seconds.
4 Time Server IP Address Array Specifies a list, in order of preference, of time servers for the client.
5 Name Servers IP Address Array Specifies a list, in order of preference, of name servers for the client.
7 Log Servers IP Address Array Specifies a list, in order of preference, for MIT_LCS User Datagram Protocol (UDP) log servers for the client.
8 Cookie Servers IP Address Array Specifies a list, in order of preference, of cookie servers (as specified in RFC 865) for the client.
9 LPR Servers IP Address Array Specifies a list, in order of preference, for Line Printer Remote (as specified in RFC 1179) servers for the clients.
10 Impress Servers IP Address Array Specifies a list, in order of preference, of Imagen Impress servers for the client.
11 Resource Location Servers IP Address Array Specifies a list, in order of preference, of RFC 887 compliant Resource Location Servers for the client.
12 Hostname String Specifies the hostname (maximum of 63 characters) for the client. NOTE:The name must start with a alphabetic character, end with an alphanumeric character, and can contain only letters, numbers, or hyphens. The name can be fully qualified with the local DNS domain name.
13 Boot File Size Word Specifies the default size of the boot image file in 512 octet blocks.
14 Merit Dump File String Specifies the ASCII path of a file in which the client's core dump can be stored in case of an application or system crash.
16 Swap Server IP Address Specifies the IP address of the client's swap server.
17 Root Path String Specifies a path (in ASCII) for the client's root disk.
18 Extensions Path String Specifies a file that includes information that is interpreted the same as the vendor extension field in the BOOTTP response, except that references to Tag 18 are ignored. Note that the file must be retrievable through TFTP.
19 IP Layer Forwarding Byte Specifies that IP packets should be enabled (1) or disabled (0) for the client.
20 Nonlocal Source Routing Byte Specifies that datagram packets with nonlocal source route forwarding should be enabled (1) or disabled (0) for the client.
21 Policy Filters Mask IP Address Array Specifies a list, in order of preference, of IP address and mask pairs that specify destination address and mask pairs, respectively. Used for filtering nonlocal source routes. Any source routed datagram whose next hop address does not match an entry in the list is discarded by the client.
22 Max DG Reassembly Size Word Specifies the maximum size datagram that a client can assemble. NOTE:The minimum size is 576 bytes.
23 Default Time to Live Byte Specifies the Time to Live(TTL) that the client will use on outgoing datagrams. Values must be between 1 and 255 hops.
24 Path MTU Aging Timeout Long Specifies the timeout, in seconds, for aging Path Maximum Transmission Unit values. NOTE:MTU values are found using the mechanism defined in RFC 1191.
25 Path MTU Plateau Table Word Array Specifies a table of MTU sizes to use when performing Path MTU (as defined in RFC 1191). NOTE:

The table is sorted from minimum value (68) to maximum value 68.

26 MTU Option Word Specifies the MTU discovery size. NOTE:

The minimum value is 68.

27 All Subnets are Local Byte Specifies whether the client assumes that all subnets in the network will use the same MTU value as that defined for the local subnet. This option is enabled (1) or disabled (0), which specifies that some subnets may use smaller MTU values.
28 Broadcast Address IP Address Specifies the broadcast IP address to be used on the client's local subnet.
29 Perform Mask Discovery Byte A value of 1 specifies that the client should use ICMP (Internet Control Message Protocol) for subnet mask discovery, whereas a value of 0 specifies that the client should not use ICMP for subnet mask discovery.
30 Mask Supplier Byte A value of 1 specifies that the client should respond to ICMP subnet mask requests, whereas a value of 0 specifies that a client should not respond to subnet mask requests using ICMP.
31 Perform Router Discovery Byte A value of 1 specifies that a client should use the mechanism defined in RFC 1256 for router discovery. A value of 0 indicates that the client should not use the router discovery mechanism.
32 Router Solicitation Address IP Address Specifies the IP address to which the client will send router solicitation requests.
33 Static Route IP Address Array Specifies a list, in order of preference, of IP address pairs the client should install in its routing cache. NOTE:

Any multiple routes to the same destination are listed in descending order or in order of priority. The pairs are defined as destination IP address/router IP addresses. The default address of 0.0.0.0 is an illegal address for a static route and should be changed if your non-Microsoft DHCP clients use this setting.

34 Trailer Encapsulation Byte A value of 1 specifies that the client should negotiate use of trailers (as defined in RFC 983) when using the ARP protocol. A value of 0 indicates that the client should not use trailers.
35 ARP Cache Timeout Long Specifies the timeout, in seconds, for the ARP cache entries.
36 Ethernet Encapsulation Byte Specifies that the client should use Ethernet version 2 (as defined in RFC 894) or IEEE 802.3 (as defined in RFC 1042) encapsulation if the network interface is Ethernet. A value of 1 enables RFC 1042, whereas a value of 0 enables RFC 894 encapsulation.
37 Default Time to Live Byte Specifies the default TTL the client should use when sending TCP segments. NOTE:The minimum octet value is 1.
38 Keepalive Interval Long Specifies the interval, in seconds, for the client to wait before sending a keepalive message on a TCP connection. NOTE:A value of 0 indicates that the client should send keepalive messages only if requested by the application.
39 Keepalive Garbage Byte Enables (1) or disables (0) sending keepalive messages with an octet of garbage data for legacy application compatibility.
40 NIS Domain Name String An ASCII string specifying the name of the Network Information Service (NIS) domain.
41 NIS Servers IP Address Array Specifies a list, in order of preference, of IP addresses of NIS servers for the client.
42 NTP Servers IP Address Array Specifies a list, in order of preference, of IP addresses of Network Time Protocol (NTP) servers for the client.
43 Vendor Specific Info Byte Array Binary information used by clients and servers to pass vendor-specific information. Servers that cannot interpret the information ignore it, whereas clients that do not receive the data attempt to operate without it.
45 NetBIOS Over TCP/IP NBDD IP Address Array Specifies a list, in order of preference, of IP addresses for NetBIOS datagram distribution (NBDD) servers for the client.
48 X Window System Font IP Address Array Specifies a list, in order of preference, of IP addresses of X Window font servers for the client.
49 X Window System Display IP Address Array Specifies a list, in order of preference, of IP addresses of X Window System Display Manager servers for the client.
64 NIS + Domain Name String Specifies a list, in order of preference, of NIS + domain names.
65 NIS + Server IP Address Array Specifies a list, in order of preference, of NIS + servers.
255 End Byte Specifies the end of the DHCP packet.

Installing the DHCP Service

You can install the DHCP Server service through the Control Panel Network applet. But before you install the service on your current server, check for the existence of other DHCP servers on the network. These could be other Windows NT Servers or a UNIX server.

To install the DHCP Server service, follow these steps:


NOTE:

To install the DHCP Server service, you must be a member of the Administrators group on the computer on which you want to install the service.


  1. Launch the Control Panel Network applet.
  2. Click the Services tab, and then the Add— button.
  3. Select Microsoft DHCP Server from the list of network services.

    NOTE:

    If you don't have TCP/IP installed already, when you install the DHCP Server Service, TCP/IP will be automatically installed.



    TIP

    To use SNMP to configure the DHCP Server service remotely, install the SNMP Service as well.


  4. Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button. Setup warns you that DHCP servers cannot also be DHCP clients and any network adapter configured as a DHCP client must be reconfigured. This message is shown in Figure 12.1.

    Figure 12.1

    Network adapters on a DHCP Server cannot be configured to dynamically obtain IP addresses.

  5. Click the OK button and then click Close to close the Network Control Panel.
  6. If one or more adapters on your server was configured to obtain its IP address from a DHCP server, or if you are installing TCP/IP at the same time as the DHCP server service, you will be prompted to configure TCP/IP settings for each adapter on your system.
  7. Now restart your system. After the system restarts, the DHCP Server service should be activated. If not, check your system event log for any error messages.

Managing Your DHCP Server with the DHCP Manager

Your interface to managing the DHCP Service is the DHCP Manager. It is installed in the Administrative Tools program group when you install the DHCP service and requires administrative privileges to use. With the DHCP Manager, you can do everything but stop or start the DHCP Service. To stop or start the service, use the Control Panel Services applet and specify the Microsoft DHCP Server as the service to control. Or, you can issue the following commands from a console prompt:

net stop dhcpserver
net start dhcpserver

The DHCP Manager's primary function is to work with scopes. This section discusses creating, deleting, activating, and deactivating scopes. Next, we discuss how to manage your DHCP clients. This includes managing your client leases and reservations, as well as setting individual DHCP properties for reserved clients that differ from those defined for the scope as a whole. Finally, we discuss the DHCP database administration required from time to time. This should provide you with a well-rounded education and prepare you for your duties as a network Administrator so that you can manage your TCP/IP-based network.

Managing DHCP Scopes

Before you can use the DHCP Server to assign IP addresses and relevant configuration options to your DHCP clients, you must create a DHCP scope. A scope is the heart of your DHCP Server service. It is based on an IP address range, or subnet, if you prefer. It can include only a single subnet, but within that subnet, you can define the IP range to be used as the basis for your DHCP client's IP address assignment, the subnet mask, any IP addresses to exclude from the scope, a lease duration, a name for the scope, and a comment that describes the scope. This section discusses how to create, delete, activate, and deactivate DHCP scopes. Next, it moves on to configuring global, local, or default scope properties.

When you run the DHCP Manager for the first time, it does not have any scopes defined, although it does include a listing in the DHCP Server's window for the local machine. Before you start creating scopes, I suggest that you add the additional DHCP Servers on your network to the DHCP Manager. When you do, your DHCP Manager includes a listing in the window of each DHCP Server on your network (see Figure 12.2). This gives you the capability to manage your other scopes, and you can use these additional scopes as a reference point when creating new scopes.

Figure 12.2

The Microsoft DHCP Manager with multiple DHCP servers and scopes.

To add DHCP Servers to your local DHCP Manager, follow these steps:

  1. Choose Add from the Server menu, or press Ctrl+A to display the Add DHCP Server to Server List dialog box.
  2. Enter the IP address of the DHCP Server in the DHCP Server field and click the OK button. The IP address appears in the DHCP Server window.

    NOTE:

    The DHCP Manager deals with TCP/IP FQDN (fully qualified domain name)-compliant hostnames—also called DNS names. It does not recognize NetBIOS names. For an in-depth description of the differences between NetBIOS names and the standard TCP/IP hostnames, refer to the section "NetBIOS names versus TCP/IP hostnames" later in this chapter.


  3. Repeat these steps for each DHCP Server you want to add to your local DHCP Manager.

    NOTE:

    Because the DHCP Server service does not replicate its database and configuration information to other DHCP Servers, you must configure the DHCP Manager on each server in order to manage all the DHCP scopes from any computer with the DHCP Manager installed on it.


Working with DHCP Scopes

Working with DHCP scopes consists of four possible functions:

To create a scope, follow these steps:

  1. Select the DHCP Server in the DHCP Server window where you want to create the new scope. If you are creating a new scope on the computer running the DHCP Server service, this entry will be Local Machine; otherwise, it will be an IP address.
  2. Choose Create from the Scope menu. The Create Scope dialog box appears, as shown in Figure 12.3.

    Figure 12.3

    The Create Scope dialog box.

  3. In the Start Address field, enter the beginning IP address of your subnet.
  4. In the End Address field, enter the last IP address of your subnet.

    TIP:

    If you are not planning to divide your subnet between two DHCP Servers, enter the complete IP address range of your subnet. However, if you are planning to split your subnet (as I have), enter only half of your IP address range in the Start and End Address fields. This is easier to work with and prevents complications with the second DHCP Manager's defined scope.


  5. In the Subnet Mask field, enter the subnet mask to be assigned to your DHCP clients.
  6. If your scope includes statically assigned addresses, such as those assigned to your network adapters in the computer or to the Remote Access Service, enter these addresses in the Exclusion Range group. To exclude a single IP address, enter the IP address in the Start Address field and click the Add button. To enter more than one consecutive IP address to be excluded, enter the beginning IP address in the Start Address field and the last IP address in the End Address field; then click the Add button. This places the IP address range in the Excluded Addresses box.
    To modify or remove an address range, select it in the Excluded Addresses box and click the Remove button. This places the range in the Exclusion Range fields where you can modify it and later add it back to the Excluded Addresses box.
  7. In the Lease Duration group, choose the Unlimited or Limited To radio button to specify the lease type. If you choose Limited To, which is the default, specify the length of time for your DHCP clients to keep their assigned IP addresses. By default the lease expiration period is set to 3 days.
    Choose your lease time on the basis of the frequency with which your computers are upgraded, replaced, or moved between subnets. If you have a high movement of computers, choose a lease of approximately two weeks. If you have an extremely low movement of computers, choose a monthly, trimonthly, or biyearly lease.

    WARNING:

    Do not assign the Unlimited lease type unless you are absolutely sure that no computers will ever be upgraded, replaced, or moved. It is very improbable that you will be in this situation, I can assure you. If you choose an unlimited lease, you cannot automatically recover IP addresses that have been assigned to a DHCP client.


  8. In the Name field, enter a name for the scope. Your name can be a floor or building location, or a description for the type of subnet. This name, along with the scope address, is listed in the DHCP Server window. It can be up to 120 characters.
  9. In the Comment field, enter a description for the scope up to 120 characters long. You should make this comment as descriptive as possible.

    TIP:

    To modify the scope properties for an existing scope, just double-click it. This displays the Scope Properties dialog box, which is identical to the Create Scope dialog box (aside from its name, of course). You can change any of the options described in the earlier steps.


  10. Click the OK button. A message box appears, prompting you to activate the scope. However, you should not activate the scope now, unless all your default scope properties are correct, as described in the "Configuring DHCP Scope Options" section.
  11. Repeat these steps for each new scope you want to create.

    CAUTION:

    Activate a scope only after you have configured it; otherwise clients might get invalid configuration information. Also, be sure to make any necessary lease reservations before activating the scope; otherwise a client other than the indented recipient might take the IP address.


To activate a scope, choose Scope | Activate.

Before you delete a scope, you should deactivate it. To do so, choose Scope | Deactivate. When the scope lease time expires and you are sure that no DHCP clients are using a lease from the scope, you can delete it.

To delete a scope, follow these steps:

  1. Select the DHCP Server in the DHCP Server window containing the scope you want to delete. If you are deleting a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
  2. The scopes for the server are listed. Select the scope you want to delete.
  3. Choose Delete from the Scope menu. A warning message appears, informing you that clients still may have active leases. Click OK to delete the scope.
  4. Repeat these actions for each scope you want to delete.

TIP:

If you delete a scope with active clients, you can force the client to discontinue using its current lease and obtain one from another DHCP Server by issuing the IPCONFIG /RENEW command at a command prompt on the client workstation. On a Windows 95 computer, you can use the WINIPCFG program. Click the Renew button to release the active lease and obtain a new lease.


Configuring DHCP Scope Options

Scope options are divided into two classes: You can have a global scope setting, which applies to all scopes for the DHCP Server, or a local scope setting, which applies only to a specific scope. Local scope properties override globally defined scope properties. This rule enables you to define common properties that apply to all scopes you create and then customize them. Suppose that you define the global router setting to contain the IP addresses for your routers using subnets. After you create a new scope, you can delete the first entry in this list and then add it back. This places the IP address entry at the end of the list. In effect, it changes the order of router preference so that the router closest to the user is used first. You can repeat this sequence to continue moving the router addresses for each subnet you create without having to type each router address manually.

To modify a scope property, follow these steps:

  1. Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
  2. After the connection to the DHCP Server has been established, the scopes for the server are listed. Select the scope you want to modify.
  3. Choose Global from the DHCP Options menu. Here, you can set global properties for all scopes. Or, you can choose Scope from the DHCP Options menu to set local scope properties.

    NOTE:

    The dialog box displayed by choosing the DHCP Options | Scope menu selection is the same as the dialog box displayed by choosing the Global menu option, aside from the name of the dialog box.


  4. In the Unused Options drop-down list box, select the option that you want to modify, and then click the Add button to move the highlight to the Active Options drop-down list box.
  5. Click the Value button to expand the dialog box and display the edit field, where you can click the Edit Array button to modify an array of IP addresses or just edit the field for a single entry type.
  6. Repeat steps 3—5 for each option to modify. When you finish modifying the options, click the OK button.

TIP:

To modify an existing option, select it in the Active Options list box and then click the Value button to expand the dialog box.


Creating New DHCP Scope Options

Not only can you modify the predefined scope properties with the DHCP Manager, but you also can modify the name, unique identifier, and comment of existing configuration options. And if your DHCP clients can use them, you can even create new scope options to be assigned to your DHCP clients. However, just because you can modify an existing configuration option or create new ones doesn't mean that you should do so arbitrarily. Only do so if absolutely necessary.

To change an existing configuration option default value, follow these steps:

  1. Choose Defaults from the DHCP Options menu to display the DHCP Options dialog box, as depicted in Figure 12.4.

    Figure 12.4

    The DHCP Options: Default Values dialog box.

  2. In the Option Class drop-down list box, select the class for the option you want to modify. The default is DHCP Standard Options.
  3. In the Option Name drop-down list box, select the entry for the option class to modify.
  4. In the Value group, specify the new value for the option.

To change a configuration option's name, unique identifier, or description, follow these steps:

  1. Repeat steps 1—3 of the preceding procedure.
  2. Click the Change button to display the Change Option Type dialog box.
  3. Now change the name of the option in the Name field, the DHCP unique identifier number in the Identifier field, or the description in the Comment field.

    WARNING:

    Changing the name or identifier may prevent a DHCP client from functioning properly. Only an expert who is aware of the consequences should modify any of these settings.


  4. After you complete all changes, click the OK button.
  5. Repeat these steps for each option you want to change.

To add a new configuration option, follow these steps:

  1. Repeat steps 1—3 for the procedure to change an existing configuration option default value.
  2. Click the New button to display the Change Option Type dialog box.
  3. In the Name field, enter a name for the new option.
  4. In the Data Type field, specify a data type. This can be one of the following:

    If the data type is an array of elements, enable the Array checkbox.

  5. In the Identifier field, enter a unique number between 0 and 255.
  6. In the Comment field, enter a description for the new option.

    WARNING:

    Adding a new configuration option should be performed only by an expert who is aware of the consequences. It must support non-Microsoft DHCP clients that require the additional options.


  7. After your changes are complete, click the OK button.
  8. Repeat these steps for each option you want to add.
Managing DHCP Clients

Managing your DHCP clients consists of working with client leases and client reservations on the DHCP Server and forcing the client to release or renew its lease on the client workstations. On a client, the main method of configuring DHCP is through the command-line program IPCONFIG.EXE.

The syntax for IPCONFIG follows:

IPCONFIG [adapter] /all /release /renew

Explanations of the syntax for this command follow:


TIP:

Use the /renew option to manually force a client to obtain a new lease from a new DHCP Server or a new DHCP scope.



NOTE:

Windows 95 does not include IPCONFIG; instead, it includes a Windows GUI application called WINIPCFG.EXE.


If executed with no parameters, the current DHCP configuration is displayed. This can be useful for determining the installed adapters and IP addresses. The following output is displayed on my WinBook XP, for example:

Windows NT IP Configuration
Ethernet adapter Elnk31:
IP Address. . . . . . . . . : 128.0.0.254
Subnet Mask . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . :
Ethernet adapter NDISLoop9:
IP Address. . . . . . . . . : 129.0.0.1
Subnet Mask . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . :

Managing Client Leases

Managing your DHCP client leases, for the most part, consists of informational displays. When you select an active scope and choose Active Leases from the Scope menu, the Active Leases dialog box appears, as shown in Figure 12.5.

Figure 12.5

The DHCP Manager Active Leases dialog box.

You can perform the following actions in the Active Leases dialog box:


TIP:

You can delete a lease by selecting the lease in the Client list and clicking the Delete button. However, this is not an action to be taken lightly, because you could wind up with a duplicate IP address on the network if the original lease is used by another computer. Suppose that you delete an active lease because you want to move the client to a new IP address. As soon as you delete the lease, reserve it (as described in the "Managing Client Reservations" section) to prevent the client from reusing the same IP address. Then force the client to establish a new lease by issuing the IPCONFIG /RENEW command on the client workstation. Or use the WINIPCFG command on a Windows 95 client and then click the Renew button to obtain a new lease.


Managing Client Reservations

Client reservations can be more useful than your average lease because you can preassign an IP address for a DHCP client. You also can change the DHCP configuration options for a DHCP client with a reserved lease. This is a pretty powerful option, because it enables you to define global and local scope options for the majority of your DHCP clients when you create the scope, and then specify the specific DHCP options for those special DHCP clients that are the exception to the rule.

To create a reservation for a client, follow these steps:

  1. Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
  2. Select the scope where you want the client reservation to occur.
  3. Choose Add Reservations from the Scope menu to display the Add Reserved Clients dialog box.
  4. In the IP Address field, enter an IP address from your current DHCP scope to be assigned to the client.
  5. In the Unique Identifier field, enter the MAC address (the network adapter's unique identifier) for the client's network adapter.
  6. In the Client Name field, enter the client computer name.
  7. In the Client Comment field, enter an optional description for the client computer.
  8. Click the Add button.
  9. Repeat steps 3—6 for each reservation to add to the scope.

Changing the configuration options for a reserved lease requires a little more work. To change a configuration option, follow these steps:

  1. Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
  2. Select the scope you want to modify.
  3. Choose Active Leases from the Scope menu to display the Active Leases dialog box.
  4. Select the reserved lease you want to modify and click the Properties button. If there are too many leases to scroll through, enable the Show Reservations Only checkbox. The Client Properties dialog box appears.
  5. Click the Options button to display the DHCP Options dialog box. This dialog box is exactly the same as the other DHCP Options dialog box.
  6. In the Unused Options list box, select the option you want to modify and then click the Add button to move the option to the Active Options list box. If the option to modify is already in the Active Options list box, just select it.
  7. Click the Value button to expand the dialog box and display the edit field, where you can click the Edit Array button to modify an array of IP addresses, or a field to edit the existing value.
  8. Repeat steps 4—6 for each option to modify. When you finish modifying the options, click the OK button.
  9. Repeat steps 3—7 for each reservation you must modify. When you finish modifying all the reservations, click the OK button.

Managing the DHCP Databases

As your DHCP Server operates day in and day out, the databases may grow or shrink as records are added or deleted. These databases are located in the %SystemRoot%\System32\DHCP directory and include the following:

Database growth affects the performance of the DHCP Server. So, as your DHCP.MDB database approaches the 10MB limit, you should compact it.

To compact your database, follow these steps:

  1. Stop the DHCP Server Service from the Control Panel Services applet or issue the net stop dhcpserver command from a console prompt.
  2. From a console prompt, run the JETPACK.EXE program located in your %SystemRoot%\System32 directory. The syntax for this program follows:

    JETPACK DatabaseName TemporaryDatabaseName
    DatabaseName is the name of the database to compact, and it can be a fully qualified path name.
    TemporaryDatabaseName is a name to use as a temporary database. It also can be a fully qualified path name.


    WARNING:

    Do not compact the SYSTEM.MDB file. If you do, the DHCP Server Service will not start. If this occurs, restore your configuration from a previous backup, or delete all your files from the %SystemRoot%\System32\DHCP and %SystemRoot%\System32\DHCP\backup\Jet directories. Next, expand the SYSTEM.MDB file from your source media and restart the DHCP Server Service. Then reconcile your database by choosing Scope | Active Leases and clicking the Reconcile button.


  3. Start the DHCP Server Service from the Control Panel Services applet or issue a net start dhcpserver command from a console prompt.

TIP:

Because failure is possible with the compact utility and data corruption is possible on your %SystemRoot% partition, you should back up your DHCP databases regularly, and definitely before you compact them. Just stop the DHCP Server Service temporarily and copy the files in the %SystemRoot%\System32\DHCP and %SystemRoot%\System32\DHCP\backup\Jet directories to another directory, or even another computer occasionally.


DHCP Relay Agent

Because DHCP relies so heavily on broadcast methods, you can run into problems when using it in a routed environment. This is because routers are typically configured to filter out broadcast messages, restricting the range of the message to the local subnet.

However, DHCP uses the well-known UDP ports originally reserved for BOOTP, ports 67 and 68, so DHCP has an advantage. BOOTP is a method used for supplying an IP address and information necessary to allow a diskless workstation to boot from the network. People needed to provide this support across subnets, so router vendors began providing mechanisms for passing ports 67 and 68 to remote subnets. This relay support is commonly known as BOOTP/DHCP relay support, and is defined in RFC 1452. Not all routers support this, and on routers that do, the default option differs.

Not all routers provide this functionality, and others required a prohibitively expensive upgrade, so Microsoft provided a DHCP relay agent. This agent runs as a service on a Windows NT 4.0 Workstation or Server and listens to UDP port 67 for DHCP Discover packets on the local subnet. When it detects such a packet, it passes this packet to one or more DHCP servers configured when you set up the Relay Agent. When the DHCP server receives the packet, it responds with a DHCP Offer, but instead of broadcasting this offer, as it would normally, it addresses it back to the DHCP relay agent. The agent then sends the offer to the client, on behalf of the DHCP server. In fact, the client doesn't even realize it's talking to an intermediary, rather than directly to the server.

Installing the DHCP Relay Agent

To install the DHCP Relay Agent service, follow these steps:


NOTE:

You must be logged on as a member of the local Administrators group to install the DHCP Relay Agent.


  1. Open the Network Control Panel applet.
  2. Click on the Services Tab.
  3. Click the Add… button, and select DHCP Relay Agent.
  4. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button. This will bring you back to the Network Control Panel. DHCP Relay Agent should now be listed as an installed service.
  5. Click the Continue button to exit the Network Control Panel.
  6. You will receive a warning message, such as that shown in Figure 12.7, telling you that you must configure at least one DHCP server address before the DHCP Relay Agent can be activated. Click Yes to bring up the Microsoft TCP/IP Properties page. 12.7

    Figure 12.7

    Setup will warn you that you must configure at least one DHCP server before the DHCP Relay Agent can be started.

  7. From the Microsoft TCP/IP Properties page, click the DHCP Relay Agent tab. This displays the DHCP Relay Agent configuration page, shown in Figure 12.8.

    Figure 12.8

    The DHCP Relay Agent is configured from the Microsoft TCP/IP Properties window.

  8. Use the Add— button to enter the addresses of the DHCP Servers you want to service the local subnet.
  9. Change the Seconds Threshold and the Maximum Hops as necessary for your particular network.

    NOTE:

    For most networks, you can leave the Seconds Threshold and the Maximum Hops values at their defaults, which is 4 seconds and 4 hops, respectively.


  10. Click OK to close the Microsoft TCP/IP Properties window.

You must restart your computer for the changes to take effect.

Using DHCP Server Registry Keys

Like most Windows NT services, the configuration information for the service is contained in the Registry. For the most part, you should use the DHCP Manager to modify your configuration. These listed Registry keys are not configurable from the DHCP Manager, and instead require that you use the Registry Editor (REGEDT32.EXE). The Registry Editor can be a dangerous tool to use. (See Chapter 18, Understanding the Registry, for more information.) If you are administering a remote computer with a configuration problem so severe that the service cannot be started, then you can modify the Registry and restore the database configuration remotely. After these changes are made, you can restart the service using Server Manager.

The Registry keys are stored in the HKEY_LOCAL_MACHINE\Systems\CurrentControlSet\Services\DHCPServer\Parameters subkey. If you modify any of these keys (aside from the RestoreFlag), you must restart the computer for your changes to be applied.

The keys of interest follow:

The Windows Internet Name Service

Now that we've taken a look at DHCP, we have a better foundation for exploring WINS. Although DHCP is not required for running WINS, they complement each other very well. The major impetus behind the creation of WINS was the need for a dynamic name resolution method that would work with DHCP. Because DNS in its standard form only supports static name resolution, it wouldn't have provided the level of necessary functionality.

So there you have it: WINS's primary job role is name registration and resolution on TCP/IP.


NOTE:

WINS is based on RFC 1001 and 1002, which define NetBIOS name resolution over TCP/IP. WINS is fully interoperable with other NetBIOS Name Servers (NBNS). These RFCs can be found at ftp://ds.internic.net/rfc/rfc1001.txt and ftp://ds.internic.net/rfc/rfc1002.txt.


But wait, you might be saying, isn't that the job of DNS? Yes it is, but there are many things that DNS cannot do. Whereas DNS is designed for resolving TCP/IP hostnames to static IP addresses, WINS is specifically designed to resolve NetBIOS names on TCP/IP to dynamic addresses assigned by DHCP.


NOTE:

It is important to understand the distinction between a NetBIOS name and a computer's TCP/IP hostname. A discussion of this can be found in the section titled "WINS versus DNS," later in this chapter.


Also, whereas DHCP is truly a cross-platform service, WINS is primarily focused on the Windows (and DOS) platforms. This is because NetBIOS is a Windows (and DOS) artifact.

This discussion of WINS begins with some of the design goals of the service, along with some of the concerns when implementing WINS on your network. It then moves on to planning your WINS Server installation, which includes some guidelines for the number of WINS Servers and WINS Proxy Agents to install. Following that, we look at the actual installation steps required to install the service. When that is out of the way, we move on to managing and configuring the WINS Service with the WINS Manager. And because a major portion of WINS involves client-related administration, you will see how you can manage your WINS clients with the WINS Manager and learn about some specific quirks for MS-DOS clients using the Microsoft Network Client network software. Finally, we look at managing your WINS database, using the Performance Monitor to monitor your WINS service, and using some of the Registry keys that control the behavior of the WINS service.

Looking at Design Goals for the WINS Service

The primary purpose of the WINS Server Service is to make an Administrator's job easier by automating the process of mapping computer names to IP addresses for NetBIOS name resolution in a TCP/IP-based network. In a nutshell, WINS maintains a database on the WINS server. This database provides a computer name to IP address mapping, enabling other computers on the network to connect to it simply by supplying a machine name. In many respects, WINS is like DNS, except it is designed for NetBIOS name resolution. There is more to WINS than just automating the name resolution process, however.

The WINS design also includes the following:

WINS Proxy Agents

As indicated previously, WINS is a relatively new service. Therefore, you might still have several NetBIOS over TCP/IP clients that cannot act as WINS clients. This is particularly true of older software and non-Microsoft NetBIOS networking clients, such as LAN Manager and other older OS/2-based clients. To enable these non—WINS-enabled clients to interact with a WINS service, Microsoft provides the capability to run WINS Proxy Agents.

A WINS Proxy Agent listens to the local network for clients trying to use broadcasts to resolve NetBIOS names. The WINS Proxy Agent picks these requests off the network and forwards them to the WINS Server, which responds with the resolved IP address. The WINS Proxy Agent provides this information to the client requesting the name resolution.

The neat thing about this process is that no changes must be made to the non—WINS-enabled client, and in fact it is completely unaware that the name resolution has been provided by the WINS service.


NOTE:

It is important to realize that the WINS Proxy Agent is only for resolving name requests for NetBIOS clients. It does not provide any name resolution for UNIX or other systems that do not use NetBIOS.


You can use Windows NT 3.5 and higher or Windows for Workgroups as WINS Proxy Agents.

WINS versus DNS

The relationship between DNS and WINS (and even DHCP) is very complicated and would require a lot of space and time to fully explore, but understanding this concept is key to getting the most from WINS and DNS on a Microsoft network.


NOTE:

This section clarifies the overall concepts behind WINS, DNS, NetBIOS names, DNS hostnames, and so on. To make this as useful as possible, I gloss over certain irrelevant parts of the puzzle, so remember, it's the overall scheme that's important here.


As discussed repeatedly throughout this book, standard TCP/IP utilities (such as FTP and TELNET) use IP addresses for establishing connections between the client and server services. Recall also that people hate to remember long IP addresses, thus the development of hostname to IP address mapping facilities, of which local HOSTS files and DNS services are the two most popular.

Whereas standard TCP/IP utilities must resolve the hostname to an IP address to locate the host on the network, Microsoft networking (a.k.a. NetBIOS networking) works differently. It does not use an actual address for locating a network resource, but rather the NetBIOS name. NetBIOS is a session layer interface protocol developed in the early 1980s for IBM. It exposes a set of networking APIs that enable user applications to obtain and provide network services. It also provided a primitive transport protocol called NetBIOS Frames Protocol (NBFP), which evolved into NetBIOS Extended User Interface (NetBEUI) a few years later. NetBEUI's sole purpose in life was to efficiently transport NetBIOS traffic across small LANs.

For many years, NetBEUI was the standard transport protocol for Microsoft networks. Today, many people still get mixed up about the role that NetBEUI and NetBIOS play. NetBEUI is inextricably linked to NetBIOS. NetBIOS, however, can be abstracted and applied to other transport protocols, such as IPX/SPX, and TCP/IP, which of course is our interest here. But first, let's look quickly at the operation of NetBIOS over NetBEUI.

Remember that NetBIOS is a session layer protocol. However, it doesn't fully comply with the ISO OSI model, so the addressing takes place inside the NetBIOS layer. Also, the addressing is done by name and not by an address, like TCP/IP.

To see why this is significant, let's look at what happens when an application requests network services with NetBIOS over NetBEUI. Some NetBIOS application decides it wants to connect to a network resource. To do this it must know the NetBIOS name that identifies the resource on the network. The application says "Okay, I want to connect to the network resource called SERVER." It speaks this command into the NetBIOS API interface. The NetBIOS layer then instructs the NetBEUI transport to find the resource on the network. "NetBIOS to NetBEUI. Please find the network resource called SERVER on the network." The NetBEUI transport does this by broadcasting to the network asking for the specified network resource to identify itself. "Hello out there. Is anyone out there called SERVER? If you are, would you please respond to me with your MAC address?" If the specified resource is on the network, it will respond with its MAC address. "Yeah, I'm SERVER. My MAC address is—" NetBEUI then uses this MAC address for passing packets back and forth between the two machines.

So you can see that it is imperative that you know the NetBIOS name of the resource you want to connect to. NetBEUI is a small and fast protocol, but because it relies heavily on broadcasts and it cannot support internetwork routing, it doesn't scale well past a small workgroup (fewer than 100 machines). That's probably a little more about NetBEUI than you wanted to know, but it is key to understanding the evolution that brought us to the confusion between WINS and DNS name resolution.

As mentioned previously, Microsoft wanted to begin running NetBIOS applications over other protocols, such as IPX/SPX and TCP/IP. This would enable Windows users to participate more extensively in large networks and perform WAN communications. Also, users who wanted to connect to standard TCP/IP-based services as well, such as FTP and TELNET servers, would only have to install a single protocol stack, which would reduce overhead.

It was simple to create a TCP/IP implementation on DOS or Windows that acted like a normal TCP/IP stack for supporting standard TCP/IP connectivity. However, the problem was how to interface NetBIOS with TCP/IP. Remember, although NetBIOS is a session-layer protocol, it uses its own resource location system based on the NetBIOS name. TCP/IP, on the other hand, relies on the IP address for resource location. The problem was getting these two to work together. The idea is quite simple, but the method can be tricky.


NOTE:

All current Microsoft stacks support NetBIOS over TCP/IP. However, many third-party TCP/IP stacks developed for the DOS and Windows environments still do not.


The essence of how NetBIOS interfaces with TCP/IP follows. The NetBIOS applications says, "I want to connect to a network resource called SERVER." The NetBIOS API interface then takes this information and passes it through a NetBIOS "helper" interface. This interface resolves the NetBIOS name into an IP address, which is required for locating the resource on an TCP/IP network. Remember, this step was not required under NetBEUI, because the NetBIOS name was actually used for locating the resource on the network.

This is the step where all the confusion usually occurs, and this is also where WINS plays its biggest role. Recall that there are four main methods of resolution, b-node, p-node, m-node, and h-node. They refer to the differing methods the NetBIOS client uses to register and resolve names on a TCP/IP network. We look more closely at each of these in the next section.

When the NetBIOS to TCP/IP interface has resolved the NetBIOS name into an IP address, the remainder of the process works the same way as standard TCP/IP. The IP address is resolved into a MAC address, either of the actual resource or of the router that can be used to locate the resource. And communications take place.

So the real question becomes, "How does this interface translate the NetBIOS name into an IP address?" Before WINS was developed, the three most common ways of performing this resolution were as follows:

Although all these options have their advantages and disadvantages, the problem that none of them addresses is how to deal with name resolution for dynamically assigned IP addresses. This is the primary reason WINS was created. Although WINS can be used as the only method of name resolution, it is more commonly used in conjunction with one or more of the previously listed methods.

When you use WINS on your network, WINS clients register their current IP addresses and their NetBIOS names with the WINS server. Then when someone on the network wants to resolve the NetBIOS name for a network resource, he or she can ask the WINS server. Even if the IP assignment is obtained dynamically with DHCP, this process still works, because every time a DHCP client gets a new address, it registers the change with the WINS server.

I address why NetBIOS names are important and how NetBIOS name resolution works on TCP/IP networks. One area that remains to be explored is how WINS and DNS can be integrated. WINS works well for NetBIOS name resolution. This means that I can use the File Manager or other NetBIOS application (such as the Network ClipBook viewer) to connect to a machine registered in the WINS database.

Let's look at an example to explore the need for integration between WINS and DNS. I have an NT server called SERVER. I have a Windows for Workgroups (WfW) workstation called WORKSTATION. If the WfW machine wants to connect to a network drive on SERVER, then it uses the NetBIOS name SERVER when it tries to connect. It uses whatever resolution method is available for resolving the NetBIOS name to the IP address. If I am also running an FTP server on the machine called SERVER, and I want to connect to that, things work differently. FTP is not a NetBIOS-based application. FTP really wants the actual IP address of the host in order to connect. This means that if the machine named WORKSTATION wants to connect to SERVER using FTP, it must be given the IP address of SERVER. Or WORKSTATION must be given a name that can be resolved in the IP address using a local HOSTS (not LMHOSTS) file or a DNS service. But let's throw in a monkey wrench. Let's say that the machine called SERVER gets its IP address dynamically from DHCP. Neither the HOSTS file nor the DNS solution are capable of resolving names to dynamic IP addresses. And remember, WINS is only capable of resolving NetBIOS names.

This is where the concept of interfacing WINS and DNS becomes important. Let's extend the example to see how this interfacing works. Imagine: I run a mostly Windows-based network of 100 clients with a few NT servers. All resources receive their IP addresses dynamically with DHCP, except one NT Server, which is the WINS and DHCP server. I also run an FTP server on one of the NT Servers on the network, which also gets its address dynamically. Suppose there is a UNIX box on the other side of the world that wants to FTP into the NT Server. One way to connect is to discover what the current IP address is for the server and use this to connect. The disadvantage is that the IP address might change, and you'll need to rediscover it.

There's no other way to connect, right? Well, that's what DNS to WINS integration is for. It works by running the Microsoft DNS Server service on Windows NT. The Microsoft DNS server, discussed in further detail in the section titled "Using the Microsoft Domain Name System (DNS) Server," later in this chapter, has a special piece of interface code that works with the WINS server service. This lets the DNS server request a name to IP resolution request from the WINS server.


NOTE:

We've just spent all this space talking about the differences between NetBIOS names and TCP/IP hostnames; yet in the last paragraph, you get the feeling the distinction became blurred. You're right. Fortunately for us, TCP/IP hostnames and NetBIOS names use a compatible set of conventions, so when using this service, the NetBIOS name and the TCP/IP hostname can be sued interchangeably.


To continue our example, the UNIX client on the other side of the world, let's say in Timbuktu, tries to connect to an NT Server called NTFTP.xyzcorp.com. Remember, this NT Server gets a dynamic IP address from a DHCP server. The UNIX client asks its local DNS server to try to resolve the name NTFTP.xyzcorp.com. The local DNS server then looks to the InterNIC for the IP address of the authoritative DNS server for domain xyzcorp.com. The InterNIC returns the authoritative server, which is the NT Server running the Microsoft DNS server and WINS server. The Microsoft DNS server is then asked for the identity of the machine called NTFTP. The Microsoft DNS server, in turn, asks the WINS server for the IP address of a machine called NTFTP. The IP address is ultimately returned to the UNIX machine in Timbuktu, which completes the connection now that it has an IP address for NTFTP.xyzcorp.com. This is an effective example of the integration between WINS and DNS.

Planning Your WINS Installation

For a small Microsoft-based network, all you really must do for your WINS installation is to install the WINS Service on each domain controller. This provides the means to configure your TCP/IP-based network clients to fully interoperate with any other server or client on the network. This recommendation is based on the fact that a single WINS Server can accommodate about 1,500 name registrations and 760 name query requests per minute. In theory, this means that you can use one WINS Server, with a backup WINS Server for every 10,000 clients. However, I prefer to use a WINS Server per logical grouping to provide additional fault tolerance and load balancing.


NOTE:

These name query requests can be routed to other WINS Servers and WINS Proxy Agents to ensure that a request eventually will be fulfilled. If you enable replication of your WINS databases, however, each WINS Server will have a complete listing of every WINS client name and IP address. Then, when a name query request is received, an IP address will be returned without broadcasting on the network. This mechanism provides the capability to decrease the amount of broadcast traffic on the subnet.


This logical grouping should be based on the physical layout of your Windows NT Server domain controllers or servers. A logical group could be based on domain controllers or servers in separate physical buildings or floors. It could even be based on domain controllers on the other side of a WAN link or similar property. For every three to five domain controllers or servers, I like to install the WINS Service. This provides for fault tolerance, in case of required maintenance or a WINS Server failure, and also limits the load on a single WINS Server. At the very least, you should have two WINS Servers on your network supplying NetBIOS name resolution to prepare for a failure of the primary WINS Server, just as you should have a primary and backup domain controller to provide logon authentication in case of a primary domain controller failure.

This scenario works well for Microsoft-based networks that use the Microsoft TCP/IP protocol stacks. But it will fail if you use third-party TCP/IP protocol stacks that do not support WINS on your network clients. This does not mean that you cannot use WINS in this situation, however; it only implies that you also must install WINS Proxy Agents. A WINS Proxy Agent should be installed on each subnet to provide a link between your non-WINS clients and the WINS Servers. Your WINS Servers also should share their database to provide complete coverage of the entire network. This sharing process is provided by WINS replication, which is discussed in detail later in this section.


NOTE:

You also can create static mappings, which add a permanent computer name to IP address mapping in the WINS database to support your non-WINS clients.


You must have a WINS Proxy Agent per subnet because broadcast messages are not passed across routers. When a non-WINS client tries to find another computer, it uses a broadcast message to get the IP address of the requested computer. If the computer is on the same subnet, the request succeeds, but if it is on a different subnet, the request fails (unless you have domain controllers on both sides of the routers). This is where the WINS Proxy Agent comes into play.

Client #1 is a WINS client, Client #2 is a non-WINS client, Client #3 is a WINS Proxy Agent, and Server #1 is a Windows NT domain controller running the WINS service. When the WINS Client #2 attempts to access WINS Client #1 by broadcasting to obtain the IP address for Client #1, the request fails because Client #1 and Client #2 are on different subnets. The broadcast is intercepted by Client #3, however, which then caches this name and IP address. Client #3 also returns the IP address for Client #1 to Client #2 so that a TCP/IP connection can be established. If another WINS client on a different subnet attempts to access Client #2 by issuing a name query request, the cached IP address for Client #2 that Client #3 has stored is returned to the requesting client.

A WINS Proxy Agent will not store information obtained from a broadcast in the WINS Server's database. You therefore must have a WINS Proxy Agent on each subnet that contains non-WINS clients. In this case, the WINS Proxy Agent can respond to name query requests from WINS clients or WINS Servers, and then broadcast on its local subnet to find the non-WINS client. After the non-WINS client is found, the IP address can be passed to the WINS client or server that issued the name query request.

When a WINS client requires access to another computer, it issues a name query request. This request can be routed to WINS Servers, but this occurs only if the primary or secondary WINS Server for the WINS client does not contain a registration for the requested computer. If the routed name query request cannot be resolved by any WINS Server, the WINS client then issues a broadcast message. Both broadcast messages and routed name query messages eat network bandwidth that could be used to pass data. If your WINS Servers have a complete listing of the computer names and IP addresses, however, the primary WINS Server then can respond to the name query request, limiting the number of routed name query requests and broadcast messages.

This leads to the next performance and planning tip, which is that every WINS Server on a network should replicate its database to other WINS Servers on the network so that every WINS Server has a complete listing of every WINS client's name and IP address. This method provides the fastest mechanism for resolving names to IP addresses and limiting broadcast messages and routed name query messages.

WINS Servers provide two mechanisms for replication:

As you can see from the description of push and pull partners, these are part of a circular process. To replicate the WINS database one way, one WINS Server must be a push partner and the other must be a pull partner. To completely replicate a WINS database between two or more WINS Servers, each WINS Server must be a push and pull partner of the other. This is a two-way nonlinear chain, as shown in Figure 12.14, which can be used to replicate every WINS database to every other WINS database. Some WINS Servers receive update notifications from more than one WINS Server, which can lead to increased network traffic.

A better method, although a bit slower, is to create a linear chain where one—and only one—WINS Server is the push or pull partner of another WINS Server. Only at a WAN link is this rule broken, where the WINS Server on the LAN side is a push and pull partner of a WINS Server on the LAN, and where it is also a push and pull partner of a WINS Server on a WAN link. And this leads to another point: How often should you replicate? My basic methodology is based on the distance between replication points and the speed of the link. For your LAN, 10㬋 minutes is a good choice because the network throughput is quite high. For local, heavily used WAN links, you should limit your replication period to 30㬸 minutes. Decrease the rate only if you have a high turnover rate. For longer WAN links, choose a value of 45㭖 minutes. And for intercontinental WAN links, choose 6㬈 hours and schedule it for the non-peak hours. The idea here is that the more heavily the link is used, the lower the replication frequency (or the higher the number of scheduled minutes between replication attempts).

Installing the WINS Service

You use the Control Panel Network applet to install the WINS Server Service.


NOTE:

To install the WINS Server Service, you must be a member of the Administrators group on the computer on which you want to install the service.


Follow these steps to install the WINS Service:

  1. Launch the Control Panel Network applet.
  2. Click the Services tab, and then the Add button.
  3. Select Windows Internet Name Service from the list of network services.

    NOTE:

    If you don't have TCP/IP already, when you install the WINS Server Service, TCP/IP will be automatically installed.



    TIP:

    To use SNMP to configure the WINS Server Service remotely, install the SNMP Service as well.


  4. Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button.
  5. Click the Close button to close the Network Control Panel.
  6. When prompted, restart your system. After the system restarts, the WINS Server Service should be activated. If not, check your system event log for any error messages.

Configuring the WINS Service with the WINS Manager

The first time you use the WINS Manager, it displays only the WINS Server on the local computer. To add WINS Servers to the WINS Manager, choose Server | Add WINS Server and then supply the IP address or computer name in the Add WINS Server dialog box. To delete a WINS Server from your WINS Manager list, select it and then choose Server | Delete WINS Server. After adding your WINS Servers to the local WINS Manager, you should configure the local WINS Server for optimal performance. This includes setting your WINS Server configuration, replication partners, and preferences. Each of these options performs a slightly different task, which this section covers.

The first recommended option is to choose Server | Configuration, which displays the WINS Server Configuration dialog box. (See Figure 12.9.)

Figure 12.9

The expanded WINS Server Configuration dialog box.

You can set the following options in the WINS Server Configuration dialog box:

I suggest setting your preferences for the WINS Manager and default settings for the WINS Service. You can access these preferences by choosing Options | Preferences to display the dialog box shown in Figure 12.10.

Figure 12.10

Specifying the WINS Manager preferences and WINS Server Services defaults.

You can take the following actions from this dialog box:

I suggest that you set the replication settings for the local WINS Server by choosing Server | Replication Partners. This displays the Replication Partners dialog box shown in Figure 12.11. Click the Add button to add the WINS Servers to be configured as the local push or pull partners. You can choose to replicate to any or all WINS Servers in a nonlinear fashion, or you can choose to pull from one WINS Server and push to another in a linear fashion. These techniques are described in more detail in the section titled "Planning Your WINS Installation."

Figure 12.11

Specifying the WINS Server replications partners.


NOTE:

To remove a WINS Server from the WINS Server list, select it and press the Delete key.


After you add your WINS Servers, you can take the following actions:


TIP:

You can initiate a complete replication to the selected WINS Server by clicking the Replicate Now button.


Managing Your Non-WINS Clients

Managing your non-WINS clients consists of creating static mappings, which is a permanent computer name—to—IP address record, and viewing your current database records. When you create a static mapping, it is also a good idea to create a reservation (as described in the section "Managing Client Reservations") for this IP address to provide a more manageable environment. You can add static mappings by choosing Mappings | Static Mappings, which displays the Static Mappings dialog box, as shown in Figure . After you click the Add Mappings button, the Add Static Mappings dialog box appears. Here, you can enter a computer name, IP address, and type that will be added to the WINS Server database. Table 12.4 describes the special names the WINS Server uses and how WINS manages these names. You can delete a static mapping by selecting the mapping in the Static Mappings dialog box and then clicking the Delete Mapping button. 12.12

Figure 12.12

The Static Mappings dialog box.


TIP:

You can import a series of static mappings by importing a host file from a DNS server to support your non-WINS computers.


Table 12.4. WINS server special names.

TypeDescription
Unique A normal name, implying that only one computer name will be associated with the IP address.
Group Does not have an associated IP address. Instead, when a group name is registered with the WINS Server and a name query request for this name is received, the WINS Server returns the broadcast address (FFFFFFFF) and the requesting client issues a broadcast message to find the requested computer.
Multihomed A name that has multiple IP addresses associated with it. A multihomed device contains two or more network adapters that can register each IP address associated with the computer by sending a special name registration packet. A multihomed group name can contain a maximum of 25 IP addresses.
Internet A group name that contains domain controller IP addresses. WINS gives preference to this name registration to the closest 25 addresses. After a request is received for the domain, the domain controller address and the additional 24 (maximum) IP addresses are returned to the client.

Managing WINS Databases

Because your WINS Server also uses the same database format (a modified Access database), it has the same basic issues as the databases for the DHCP Server. As records are added and deleted, the database grows. The WINS databases are located in the %SystemRoot%\System32\WINS directory and include the following:

The database growth affects the performance of the WINS Server. As your WINS.MDB database approaches the 30MB limit, you should compact it. To do so, follow these steps:

  1. Stop the WINS Server Service from the Control Panel Services applet, or issue the net stop wins command from a console prompt.
  2. From a console prompt, run the JETPACK.EXE program, which is located in your %SystemRoot%\System32 directory. The syntax for this program follows:
    JETPACK DatabaseName TemoraryDatabaseName
    Here, DatabaseName is the name of the database to compact. It can be a fully qualified path name.
    TemporaryDatabaseName is a name to use as a temporary database. It also can be a fully qualified path name.

    WARNING:

    Do not compact the SYSTEM.MDB file. If you do, the WINS Server service will not start. If this occurs, restore your configuration from a previous backup.


  3. Start the WINS service from the Control Panel Services applet, or issue a net start wins command from a console prompt.

TIP:

Before you back up or compact the database, choose the Mappings | Initiate Scavenging command to delete old records that are no longer needed.



TIP:

Because the potential for failure or just plain data corruption on your %SystemRoot% partition is possible with the compact utility, you should back up your WINS databases regularly, and definitely before you compact it. You can do this by choosing Mappings | Backup Database. Be sure to perform a full backup by disabling the Perform Incremental Backup option if you plan to use this copy to restore your configuration.


Monitoring the WINS Server Service

Although the WINS Manager displays the same statistics as those used by the Performance Monitor, the WINS Manager can display only the statistics for the currently selected WINS Server. If you use the Performance Monitor, however, you can monitor multiple WINS Servers simultaneously. This can be of enormous benefit when you are comparing the performance of multiple WINS Servers. Table 12.5 lists the available WINS Server performance object counters that you can use to monitor your selected WINS Server. For additional details on how to use the Performance Monitor, see Chapter 19 titled Performance Tuning and Optimization.

Table 12.5. The Performance Monitor object types and object counters for the WINS server.

Object Counter Description
Failed Queries/secTotal number of failed queries per second.
Failed Releases/secTotal number of failed releases per second.
Group Conflicts/secThe rate at which group registration received by the WINS Server resulted in conflicts with records in the database.
Group Registrations/secThe rate at which group registrations are received by the WINS Server.
Group Renewals/secThe rate at which group renewals are received by the WINS Server.
Queries/secThe rate at which queries are received by the WINS Server.
Releases/secThe rate at which releases are received by the WINS Server.
Successful Queries/secTotal number of successful queries per second.
Successful Releases/secTotal number of successful releases per second.
Total Number of Conflicts/secThe sum of the unique and group conflicts per second. This is the total rate at which conflicts were seen by the WINS Server.
Total Number of Registrations/secThe sum of the unique and group registrations per second. This is the total rate at which registrations are received by the WINS Server.
Total Number of Renewals/secThe sum of the unique and group renewals per second. This is the total rate at which renewals are received by the WINS Server.
Unique Conflicts/secThe rate at which unique registrations and renewals received by the WINS Server resulted in conflicts with records in the database.
Unique Registrations/secThe rate at which unique registrations are received by the WINS Server.
Unique Renewals/secThe rate at which unique renewals are received by the WINS Server.


TIP:

To get a feel for how well your WINS Server is performing, monitor the total number of conflicts, registrations, and renewals. You also should monitor the failed queries and releases.


Using WINS Server Registry Keys

The WINS Server Service also stores its configuration information in the Registry, just as the DHCP Server Service does. And, once again, you may need to modify the Registry to modify one or more configuration settings if you cannot set them from the WINS Manager or you are administering an inactive WINS Server. I am issuing this warning again because if improperly used, the Registry Editor can damage your system beyond repair. Refer to Chapter 21, "Understanding the Registry," for additional information and some tips for backing up your current Registry before using the Registry Editor (REGEDT32.EXE).

The following primary Registry keys are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Parameters key:


NOTE:

If the UseSelfFndPnrs option is enabled, the WINS Service only configures WINS Servers as push and pull partners across routers if the routers support multicasting. Otherwise, only WINS Servers found on the local subnet are configured automatically as partners. If your routers do support multicasting, UseSelfFndPnrs can be a useful item to set because it relieves you of the burden of configuring your push and pull partners manually.


You can configure the following Registry keys by choosing Server | Configuration and modifying the entries in the WINS Server Configuration dialog box:

The following Registry keys for partner replication are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Partners key:

Using the Microsoft Domain Name System (DNS) Server

Unlike WINS and DHCP, which are barely two years old, the DNS is a relative old-timer in the TCP/IP arena. The primary purpose of a DNS is to supply friendly computer names instead of an IP address to locate a resource. This process is often referred to as name resolution. The DNS was developed a number of years ago to solve the problems of dramatic growth in the Internet and is defined in RFCs 1034 and 1035. Because its development centered around the Internet, which has no single authority, DNS utilizes a hierarchical architecture that allows the distribution of the name database and the decentralization of administrative tasks.

WINS and DNS share many similarities, but they also have numerous differences, in both the scope of their jobs and their actual implementation. Whereas WINS provides dynamic name resolution, DNS is based on static configuration files. DNS, on the other hand, allows hierarchical naming, whereas WINS, because of its ties to NetBIOS, only provides for a flat filename space. The major job of WINS is to provide name registration and resolution, whereas DNS also provides other services, such as mail exchange information that enables electronic mail to be properly routed for the entire domain. On a more bit-pushing level, DNS uses UDP port 53, and WINS uses UDP ports 137 and 138, which are reserved for NetBIOS name services.


CAUTION:

Do not confuse the TCP/IP domain with the NT domain. DNS uses a hierarchical naming system, which is composed of a computer name and a domain name. The domain name provides information for locating the computer. An NT domain, in contrast, is a security database for managing an NT network. The computer's NT domain name, which follows a flat-file naming scheme, will always be different from the DNS domain name, which follows a hierarchical naming scheme. For example, an NT system might be a member of the XYZ-PROCURE NT domain, but its TCP/IP DNS domain name is xyzcorp.com.


The Design Goals for the Microsoft DNS service

Although you can use other DNS servers on your network, the Microsoft DNS Service that ships with NT Server 4.0 is the only one that can integrate with the WINS service to provide dynamic DNS. This is the real difference between the Microsoft DNS implementation and other DNS servers that run under Windows NT. The Microsoft implementation fully supports WINS, which in turn is aware of DHCP. If you use DHCP, WINS, and DNS together, then you too have the following capabilities:

This combination of DHCP, WINS, and DNS provides additional benefits as well. Dynamic address allocation also means dynamic address recovery. When a new IP address is allocated to a client on another subnet, then the old address is released back to the DHCP scope's address pool. This can prevent the confusion caused by a duplicate IP addresses on the network. The only thing DHCP and WINS will not do for you is make it easy to get on the Internet. One of the requirements for registering your Internet domain with the InterNIC is that you maintain two or more DNS servers on your network so that clients that want to connect to your server, most likely your WWW page, can find you. You'll find that many Internet Service Providers (ISPs) don't know how to deal with, or support, DHCP and WINS. So you may as well get used to using a DNS server if you plan to connect to the Internet, but you don't have to go through all the hassle of modifying your configuration files every time you move or add a client to your network if you also use DHCP and WINS.

Another benefit of using a DNS server is that it can provide some additional name resolution capabilities that WINS cannot. A DNS server includes e-mail name resolution by supporting the MX record type, which associates an e-mail address with a hostname. And when a DNS server cannot resolve a name locally, it will refer the name query to another DNS server higher up the chain in a effort to resolve it.

Planning Your DNS Installation

First, consider who will be in charge of maintaining the configuration files. DNS is not a simple subject to be taken lightly. Entire books have been written discussing all the nuances associated with configuring DNS servers. Fortunately, Microsoft has included a graphical configuration tool, the DNS Manager, for working with the DNS service in NT Server 4.0. This utility enables you to forgo the archaic process of editing configuration files by hand. If you use the Microsoft DNS service, you are not forced to use the graphical configuration tool. But if you prefer, you can edit the configuration files by hand.


CAUTION:

A duplicate hostname, or IP address, on your network can cause serious problems. Make sure your administrators are aware of this and that your registration plan includes the capability to register a name and IP address before it is reassigned. An access database could be used to maintain information (hostname, IP address, filename, and so on) about your network and could be queried to verify that the hostname and IP address are not in use.


First and foremost, make sure that everyone who will make modifications to the DNS service has the proper training to understand the consequences of their actions. It took a lot of people with doctoral degrees quite some time to make DNS as complicated as it ended up!

There are three main ways to configure your DNS service:

On a larger network, you might consider running multiple DNS servers to serve different subnets. This is an effective means of providing load balancing, fault tolerance, and improving network performance by limiting network traffic associated with name resolution.

Installing the Microsoft DNS Server Service

You can install the DNS Server service through the Network Control Panel applet. Follow these steps:


NOTE:

To install the Microsoft DNS Server service, you must be a member of the Administrators group on the computer on which you want to install the service.


  1. Launch the Control Panel Network applet.
  2. Click the Services tab, then the Add— button.
  3. Select Microsoft DNS Server from the list of network services.

    NOTE:

    If you don't have TCP/IP already, when you install the DNS Server Service, TCP/IP will be automatically installed.


  4. Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button.
  5. Click the Close button to close the Network Control Panel.
  6. Restart your system.

When you restart your system, the DNS Server will start automatically.

Managing the DNS Server with the DNS Manager

Your interface to managing the DNS Service is the DNS Manager. It is installed in the Administrative Tools program group when you install the DNS service. You must have administrative privileges to use this program. With the DNS Manager, you can do everything but stop or start the DNS Service. To stop or start the service, use the Control Panel Services applet and specify the Microsoft DNS Server as the service to control. Or, you can issue the following commands from a console prompt: net stop dns net start dns

The DNS Manager enables you to work with the DNS zones, the administrative unit in the DNS. This section discusses how to create a zone, create domains and subdomains within the zone, and manage hosts and other records in a domain. We also explore and learn more about the configuration files that form the heart of the DNS database. We also demonstrate how to configure the Microsoft DNS server service to take advantage of the WINS server for name resolution.

Creating a Zone

A zone is the administrative unit in the domain name system, so the first thing to do when you install the DNS service is to create a zone. A zone represents a subtree of the DNS, such as xyzcorp.com. For example, you could configure your system such that the domain xyzcorp.com, the subdomain eng.xyzcorp.com, and the subdomain admin.xyzcorp.com are all part of a single administrative zone configured by one organization. A separate organization could then be responsible for maintaining a zone that consists of the subdomains research.xyzcorp.com and testing.xyzcorp.com. This is part of the distributed nature of DNS.

The interface of the DNS Manager is similar the DHCP Manager and the WINS Manager. The first time you launch the DNS Manager tool it shows address of the local machine, as shown in Figure . 12.13

Figure 12.13

By default the DNS Manager focuses on the local machine.

If you have other NT Servers on the network running DNS, you can add them to the DNS Manager display using the following steps:

  1. Choose New Server from the DNS menu.
  2. Type in the fully qualified domain name or the IP address of the NT Server you wish to administer.
  3. Click OK. The IP address or hostname appears under the Server List.
  4. Repeat these steps for each NT Server running the DNS service you want to administer from your local machine.

NOTE

You can only use the DNS Manager to administer NT Servers running the DNS service. As nice as it would be, the DNS Manager cannot be used to configure non-NT DNS servers, such as those running on the UNIX platform.


To create an administrative zone, follow these steps:

  1. In the Server List, click the DNS server you want to administer.
  2. Choose New Zone from the DNS menu. The Create New Zone window appears.
  3. Choose Primary, and click the Next button.
  4. Give your zone a name, such as xyzcorp.com. You must also enter a filename for the zone. All the information for this zone is stored in %systemroot%\system32\dns\filename, where filename is the name of the file you enter here.
  5. Click the Next button, then click the Finish button.

The zone is now created and should appear under the listing for your server, as shown in Figure 12.14.

Figure 12.14

The xyzcorp.com zone now exists as an administrative unit on the local server.

By default, two records are created in the domain, an NS entry and an SOA entry. The NS record specifies the selected machine as a name server in the domain, and the SOA record is known as the Start of Authority. Every domain must contain an SOA, which details the name server that is the best source of authoritative information for the zone, as well as the e-mail address of a contact responsible for the domain.

Enabling WINS Resolution for the Zone

You can enable WINS resolution on a zone-by-zone basis. When the DNS is asked to resolve a DNS name and it can't find an entry for the name anywhere in the DNS database, the NT DNS service takes the left-most part of the hostname (the characters up to the first period) and passes this to the WINS server for resolution. If the WINS server has a matching NetBIOS name in its database, it returns the corresponding IP address to the DNS service, which returns it to the client. The client can then attach to the resource. As you can see, this is an effective means of permitting the DNS service to resolve even dynamically assigned IP addresses, because the WINS server understands dynamic addressing.


NOTE:

The NT DNS server will only attempt to use WINS for resolution if it cannot find a matching hostname anywhere in its database.


To enable WINS resolution for a particular zone, follow these steps:

  1. Click the zone for which you want to enable WINS resolution.
  2. Choose Properties from the DNS menu.
  3. Click the WINS Resolution tab.
  4. Check the box for Use WINS Resolution.
  5. Enter WINS Servers in the order they should be queried, as shown in Figure 12.15

    Figure 12.15

    Enter WINS servers in the order they should be queried.

  6. Click OK to close the properties window for the zone.
  7. A WINS server record should appear in the zone information list for each WINS server you configured, as shown in Figure 12.16.

Figure 12.16

A zone record is created for each WINS server to be used for resolution.

Creating Subdomains

The DNS is a hierarchical naming system. This means that you can create nested domains to divide the network into administrative units. For most standard configurations, especially those connected to the Internet, your zone name will be the same as your base domain. For example, my company is called XYZ Corporation, so our domain is xyzcorp, but it is part of the .com hierarchy. So my complete domain name is xyzcorp.com. Now I can subdivide that domain into additional units by creating subdomains. For instance, if I want to use different domains for our administrative group and our testing group, I could call them admin.xyzcorp.com and testing.xyzcorp.com.

To create subdomains, use the following procedure:

  1. Click the zone where you want to create a subdomain.
  2. Choose New Domain from the DNS menu.
  3. Enter the name for the subdomain, such as admin or testing, and click OK.
  4. The new subdomain appears under the selected zone in the DNS Manager, as shown in Figure 12.17.

    Figure 12.17

    Subdomains appear under their respective zones.


TIP:

You can create hostnames with the same name as a subdomain. For instance, admin.xyzcorp.com can refer to a machine name, but it can also refer to a subdomain that contains other machines, such as ftp.admin.xyzcorp.com.


Adding Hosts to a Domain

Now that you have created a domain, you can add hosts to populate it. To add a host, follow these steps:

  1. Click the domain (zone) or subdomain where you want the host to reside, such as xyzcorp.com.
  2. Choose New Host from the DNS menu.
  3. Enter the hostname and IP address, such as secundus and 128.1.1.2.
  4. To create an associated PTR record, click the Create Associated PTR Record button.
  5. Click the Add Host button, then click the Done button.
  6. A new record of type A is created for the host, as shown in Figure 12.18 for secundus.

Figure 12.18

A record of type A is created when you add a new host.

Adding a New Record

As mentioned earlier, the DNS provides many more services than just simple name—to—IP address resolution. Other services are provided by adding appropriate records to the domain. For instance, to specify a server to handle incoming e-mail for computers in the domain, you could create an MX record to identify the mail server.

To add records to the domain, follow these steps:

  1. Click the zone or subdomain where you want to create the new record.
  2. Choose New Resource from the DNS menu. The New Resource Record windows appears.
  3. Select the type of record you want to create, for example, an MX record. A description of the selected record type appears at the bottom of the screen, and the fields on the right change depending on the requirements of the particular record type, as shown in Figure 12.19.

    Figure 12.19

    The MX record type is used to specify a mail exchanger for the domain.

  4. Enter the remaining information required for the particular record type, such as the mail exchanger's DNS name and preference number in the case of an MX record type.
  5. Click OK.

The new record now appears in the domain listing.

The DNS Service Configuration Files

If you are the kind of person who likes to look at the nuts and bolts to see how things work, you actually have the option of directly viewing and editing the DNS configuration files. They are stored in the %systemroot%\system32\dns directory. The configuration files used with the Microsoft DNS server can be replaced by those from a UNIX BIND installation if you are migrating or interoperating with a UNIX system—although you may need to modify the files if you are using some outdated BIND commands.


NOTE:

Before editing the DNS files directly, make sure they are up to date by issuing the Update Server Data Files command from the DNS menu in the DNS Manager application.


The configuration files for BIND are divided into four basic types:

BOOT

There are very few commands supported in the boot file, so the syntax for the commands, as summarized in Table 12.6, is fairly easy to remember. An example BOOT file for a simple network, such as the one in my office, looks like this:

; DNS BOOT FILE - Master configuration for DNS service
directory %System32%\system32\dns
cache . cache
primary xyzcorp.com xyzcorp.dom
primary 127.in-addr.arpa arpa-127.rev
primary 128.1.1.in-addr.arpa arpa-128.rev

Table 12.6. Applicable commands for the BOOT file.

Command Required Description Note
;NoStarts a comment. Avoid using unnecessary comments because the file is parsed line by line. Each comment added to the file slows down name resolution for any name not in the cache.
directory PathName No Describes the location of the DNS configuration file where PathName is a fully qualified path. The default, if not specified is %SystemRoot%\Sysstem32\DNSIf the directory cannot be found, then the DNS service will not start.
cache FileName Yes Describes the location of the cache file used to find additional name servers, where FileName is the name of the file.If the file cannot be found, the DNS service will not start
Primary
DomainName
FileName
YesSpecifies a domain DomainName name for which FileName this DNS server is authoritative and a configuration file name that contains information for the domain.
Secondary
DomainName
HostList [FileName]
NoSpecifies a domain name and associated IP address array from which to download zone information.If a filename is specified, then the zone information will be downloaded and used if the domain DNS server, or alternate, cannot be located

CACHE

The cache file is used for additional name resolution. When your DNS server cannot resolve a name, it queries the additional name servers listed in this file. If you are using this DNS server to resolve names on the Internet, your file should look similar to the following:


; DNS CACHE FILE
; Initial cache data for root domain servers.
; YOU SHOULD CHANGE:
; - Nothing if connected to the Internet. Edit this file only when
; update root name server list is released.
; OR
; - If NOT connected to the Internet, remove these records and replace
; with NS and A records for the DNS server authoritative for the
; root domain at your site.
; Internet root name server records:
; last update: Sep 1, 1995
; related version of root zone: 1995090100
; formerly NS.INTERNIC.NET
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
; formerly NS1.ISI.EDU
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
; formerly C.PSI.NET
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
; formerly TERP.UMD.EDU
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
; formerly NS.NASA.GOV
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
; formerly NS.ISC.ORG
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 39.13.229.241
; formerly NS.NIC.DDN.MIL
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
; formerly AOS.ARL.ARMY.MIL
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
; formerly NIC.NORDU.NET
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
; End of File


NOTE:

An updated version of this file can be found at the InterNIC FTP site ftp.rs.internic.net. Just log on anonymously, change to the domain directory and download the file named.root.


If this DNS server will not be used for Internet name resolution, then replace the name server (NS) and address records with the authoritative DNS server for your domain.

PLACE.DOM

PLACE.DOM is the heart of your DNS server's operation. It contains several record types, as summarized in Table 12.7, which are used to provide name resolution for the domain. Because the example file included with the Microsoft DNS service contains information for a nonexistent domain, you should rename the file and modify it as appropriate for your domain. The following is a copy of my replacement file called xyzcorp.dom. I use a naming convention of DomainName.dom, and I recommend you do as well. This is particularly useful when administering multiple domains.

@ IN SOA primus.xyzcorp.com. admin.primus.xyzcorp.com. ( ;source host e-mailaddr
1 ; serial number of file
10800 ; refresh interval
3600 ; retry interval
604800 ; expiration interval
86400 ) ; minimum time to live
@ IN NS primus.xyzcorp.com. ; name server for domain
primus IN A 128.1.1.1 ; IP address of name server
@ IN WINS 128.1.1.1 128.1.1.2 ; IP address of WINS servers
localhost IN A 127.0.0.1 ; loop back
@ IN MX 10 primus ; e-mail server
primus IN A 128.1.1.1 ; IP address of e-mail server
ftp IN CNAME primus ; alias name for FTP service
www IN CNAME primus ; alias name for WWW service
gopher IN CNAME primus ; alias name for Gopher service

The first entry in the file must be a SOA record. This record includes parameters that describe the source host (where the file was created); an e-mail address for the administrator of the file; a serial number (or version number) of the file; a refresh interval (in seconds), which is used by secondary servers to determine when a revised file should be downloaded; retry time (in seconds), which is used so that secondary servers will wait before attempting to download the file in case of error; and expiration time (in seconds), which is used by secondary servers to determine when to discard a zone if it could not be downloaded. Then your name servers (or DNS servers) for the domain should be listed followed by their IP addresses. Next, include the LocalHost identifier, which is used for loop back testing, the name and address of any mail servers, and hostname aliases. A hostname alias is used to provide a host (such as my server primus) with more than one hostname. This is particularly useful when you want your WWW site to be accessible in the commonly used format WWW.DomainName.COM (www.xyzcorp.com, for example) rather than ServerName.DomainName.COM (primus.xyzcorp.com, for example).


NOTE:

When you specify a fully qualified domain name (FQDN), it must be appended with a period; otherwise the domain name is appended to the hostname for resolution and can cause the name query to fail. For example, if I had specified my domain name as xyzcorp.com in line 7 instead of xyzcorp.com. Then when trying to resolve the hostname primus.xyzcorp.com, the domain name of xyzcorp.com would be appended once again (primus.xyzcorp.com.xyzcorp.com). Because there is no host by that name, the query would fail.


Table 12.7. Supported domain name records.

Identifier Record Type Description
A Address Specifies the IP address of the associated hostname.
CNAME Class Name Specifies an alias for the associated hostname.
MX Mail Specifies the e-mail server hostnames.
NS Name Server Specifies the DNS servers in the domain.
SOA Start of Authority The first record in any configuration file, used to specify name.
WINS WINS Specifies the IP addresses of WINS servers used for additional name resolution.

ARPA-###.REV

ARPA-###.REV is used for reverse lookups of hostnames within a domain. Instead of resolving a name to an IP address, a reverse lookup resolves an IP address to a hostname. For example, for my domain, which only has one subnet (128.0.0.0), the reverse lookup file is as follows:

@ IN SOA primus.xyzcorp.com. admin.primus.xyzcorp.com. ( ;source host e-mailaddr
1 ; serial number of file
10800 ; refresh interval
3600 ; retry interval
604800 ; expiration interval
86400 ) ; minimum time to live
@ IN NS primus.xyzcorp.com. ; name server for domain
@ IN NBSTAT xyzcorp.com. ; domain name to append for NBSTAT lookups
1 IN PTR primus.xyzcorp.com. ; primus at 128.1.1.1
99 IN PTR winbookxp5.xyzcorp.com. ; WinBook XP5 at 128.1.1.99

Once again, the first record should be a SOA record. The next record lists the name (or DNS) server for the domain, followed by an NBSTAT record, then the individual PTR records for each host in the domain. These records and their usage are summarized in Table 12.8. What is generally most confusing is the PTR records. Instead of supplying a complete IP address (such as 128.1.1.1) for the host, you only supply the last digit of the IP address (such as 1) followed by the fully qualified hostname (host + domain name).

Table 12.8. Supported reverse lookup records.

Identifier Record Type Description
NBSTAT NBSTAT Specifies the domain name to append to any hostname found by an NBSTAT lookup.
NS Name Server Specifies the DNS servers in the domain.
PTR Pointer Specifies an IP address for a host.
SOA Start of Authority The first record in any configuration file, used to specify name

Summary

This chapter's focus is on implementing the DHCP, WINS, and DNS services on your network. We discuss the design goals for the services, basic planning issues, and the management options available for manipulating your DHCP and WINS clients.

We also mention specific issues for utilizing DHCP and WINS in a mixed Windows NT and UNIX environment, and, where prudent, how to prepare for the possibility of a failure with the services database, some registry keys you can use to configure otherwise unconfigurable options, and some basic performance tips.

Previous Page Page Top TOC Next Page