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 (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.
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:
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.
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:
TIP: If your routers do not support RFC 1542, you can use the DHCP Relay Agent included with NT Server. For more information on BOOTP/DHCP relay, see RFC 1542, which can be found at ftp://ds.internic.net/rfc/rfc1542.txt.
B-node (Broadcast mode): Resolves names using broadcast messages. This option is the worst possible one to use because it can flood your network segment with broadcast messages, lowering your network's capability to carry data over the network and effectively lowering your network bandwidth on the segment. Broadcasts also are not forwarded by routers, so if the requested resource is on the other side of a router, it will not be found. I recommend this type for a small network with a single subnet, one that does not have a dedicated network Administrator to maintain the network. (Using broadcasts can essentially eliminate the need to maintain an LMHOSTS file or WINS database, and for a small network, very little network bandwidth is eaten by the broadcasts.) Another good reason to use B-node is that computers located on the same segment still can find each other even if the WINS server or DNS server is down or unavailable.
P-node (Point-to-point mode): Resolves names with a NetBIOS name server (NBNS), such as WINS,) using point-to-point communications. Point-to-point communications are based on an IP-address-to-IP-address communication linkage. This is an efficient mechanism, but if the NBNS goes down, clients will be left without any method of locating other machines on the network.
M-node (Mixed mode): Uses B-node first (broadcasts) to resolve the name and then uses P-node (name queries) if the broadcast fails to resolve a name. This method works, but it has the same problem as a B-node because it can flood the network with broadcasts.
H-node (Hybrid mode): This is the default node type when configuring TCP/IP manually, unless the WINS IP address field is left empty. It uses P-node first (name queries) to resolve the name and then B-node (broadcasts) if the name service is unavailable or if the name is not registered in the WINS Server's database. I recommend this node type because it first uses a point-to-point connection to find a resource's IP address; it uses a broadcast to find the resource only if that fails. This is the most efficient node type to use, and it practically guarantees that the resource will be found even if the LMHOSTS file or WINS database does not contain the requested resource's IP address.
TIP: If you have a corrupted primary database file and this is not detected by the DHCP service, you can force the backup copy to be used by editing the Registry. Set the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\RestoreFlag to 1. Then restart the DHCP service by using the following commands:
net stop dhcpserver
net start dhcpserver
TIP: A good lease minimum should be based on your network turnaround. If you have many portable computer users, frequent computer upgrades, or many users passing between subnets, then you should have a lease time of about two weeks. This returns the unused IP addresses back to the pool, quickly making them available for reassignment. However, if you have a pretty static network, lease times of six months could be used. The one lease to avoid is an unlimited lease because these addresses will never be released automatically and returned to the IP address pool.
Another factor to consider in determining lease duration is the ratio of machines to IP addresses. For instance, if you have more machines on the network than IP address, you should consider using a much shorter lease duration, such as an hour or 30 minutes. This situation might occur if you connect your office to the Internet and have a limited number of IP addresses that must be shared among all machines on the network.
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/NBNS | IPAddress Array | Specifies 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 Type | Description |
|---|---|---|---|
| 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. |
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.
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.
Network adapters on a DHCP Server cannot be configured to dynamically obtain IP addresses.
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.
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.
The Microsoft DHCP Manager with multiple DHCP servers and scopes.
To add DHCP Servers to your local DHCP Manager, follow these steps:
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.
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 consists of four possible functions:
To create a scope, follow these steps:
The Create Scope dialog box.
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.
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.
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.
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:
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.
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:
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.
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.
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:
The DHCP Options: Default Values dialog box.
To change a configuration option's name, unique identifier, or description, follow these steps:
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.
To add a new configuration option, follow these steps:
If the data type is an array of elements, enable the Array checkbox.
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.
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 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.
The DHCP Manager Active Leases dialog box.
You can perform the following actions in the Active Leases dialog box:
The Client Properties 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.
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:
Changing the configuration options for a reserved lease requires a little more work. To change a configuration option, follow these steps:
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:
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.
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.
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.
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.
Setup will warn you that you must configure at least one DHCP server before the DHCP Relay Agent can be started.
The DHCP Relay Agent is configured from the Microsoft TCP/IP Properties window.
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.
You must restart your computer for the changes to take effect.
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:
You cannot specify a network drive because the DHCP Manager does not support remote drives for backup or recovery.
If you change this value, you must stop and then restart the service for the changes to be applied.
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.
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:
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.
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.
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).
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:
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.
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.)
The expanded WINS Server Configuration dialog box.
You can set the following options in the WINS Server Configuration dialog box:
NOTE: The extinction interval and extinction default for a fully configured WINS Server is based on the renewal time and whether the WINS Server has replication partners on the replication time interval.
TIP: You can manually scavenge the database by choosing Mappings | Initiate Scavenging. This process removes outdated records from the database.
NOTE: You can display the current value by choosing View | Database from the menu. To see the version numbers on other WINS Servers, choose the WINS Server before making the menu selection.
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.
Specifying the WINS Manager preferences and WINS Server Services defaults.
You can take the following actions from this dialog box:
NOTE: The WINS Manager display is also refreshed automatically whenever you initiate an action with the WINS Manager.
0x0 Specifies that the NetBIOS name is used by the Redirector.
0x1 Specifies that the NetBIOS name is used by the master domain browser.
0x3 Specifies that the NetBIOS name is used by the messenger service.
0x20 Specifies that the NetBIOS name is used by a LAN Manager server.
0x1B Specifies the master browser name that clients and browsers use to contact the master browser.
0x1E Specifies that the NetBIOS name is used for a normal group.
0x1D Specifies that the NetBIOS name is used for client name resolution when an attempt is made to contact the master browser for server lists.
0x1C Specifies that the NetBIOS name is an Internet group name. An Internet group name contains the addresses of the primary and backup domain controllers for the domain. This name is limited to 25 addresses.
Start Time: The time to start your WINS Server database replication. There is no default, although I like to start at 12:00 a.m.
Replication Interval: The interval at which to repeat the WINS Server database replication. There is no default, although I generally choose a 15-minute interval for LAN WINS Servers.
New Push Partner Default Configuration: The entry in this group specifies the number of changes that must occur in the WINS Server database before a push notification is sent to the push partners that you create for the currently selected WINS Servers.
Update Count: This specifies the number of changes that must occur before a push notification is sent. There is no default, although I recommend a value of 1,000.
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."
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:
Push Partners: If enabled (the default), push partners of this WINS Server are displayed.
Pull Partners: If enabled (the default), pull partners of this WINS Server are displayed.
Other: If enabled (the default), any nonpartner of this WINS Server is displayed.
Push Partner: This specifies that the selected WINS Server is a push partner. You can then click the Configure button to display the Push properties dialog box, where you can view or set the update count.
Pull Partner: This specifies that the selected WINS Server is a pull partner. You can then click the Configure button to display the Pull properties dialog box, where you can view or set the start time and replication interval.
TIP: If you specified the default values in the Preferences dialog box, these settings are set automatically for new push or pull partners. If you are configuring a push or pull partner across a WAN link, however, you should set higher values, as described in the section titled "Planning Your WINS Installation."
Push: This initiates a push trigger to send to the selected WINS Server.
Pull: this initiates a pull trigger to send to the selected WINS Server.
Push with Propagation: This modifies the Push message to indicate that changes sent to the selected WINS Server should be propagated to all other pull partners of the selected WINS Servers.
TIP: You can initiate a complete replication to the selected WINS Server by clicking the Replicate Now button.
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
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.
| Type | Description |
|---|---|
| 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. |
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:
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.
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.
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/sec | Total number of failed queries per second. |
| Failed Releases/sec | Total number of failed releases per second. |
| Group Conflicts/sec | The rate at which group registration received by the WINS Server resulted in conflicts with records in the database. |
| Group Registrations/sec | The rate at which group registrations are received by the WINS Server. |
| Group Renewals/sec | The rate at which group renewals are received by the WINS Server. |
| Queries/sec | The rate at which queries are received by the WINS Server. |
| Releases/sec | The rate at which releases are received by the WINS Server. |
| Successful Queries/sec | Total number of successful queries per second. |
| Successful Releases/sec | Total number of successful releases per second. |
| Total Number of Conflicts/sec | The 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/sec | The 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/sec | The 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/sec | The rate at which unique registrations and renewals received by the WINS Server resulted in conflicts with records in the database. |
| Unique Registrations/sec | The rate at which unique registrations are received by the WINS Server. |
| Unique Renewals/sec | The 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.
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:
You can set the InitTimeReplication key value by choosing Options | Preference and clicking the Advanced button to expand the dialog box.
You can change this value and place it into effect without restarting the WINS service.
If you choose to enable this setting, make sure that you monitor the system with the performance monitor to ensure that the WINS service is not using too much processor time and that other applications and services continue to function properly.
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:
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.
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.
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.
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.
NOTE: If you don't have TCP/IP already, when you install the DNS Server Service, TCP/IP will be automatically installed.
When you restart your system, the DNS Server will start automatically.
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.
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
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:
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:
The zone is now created and should appear under the listing for your server, as shown in 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.
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:
Enter WINS servers in the order they should be queried.
A zone record is created for each WINS server to be used for resolution.
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:
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.
Now that you have created a domain, you can add hosts to populate it. To add a host, follow these steps:
A record of type A is created when you add a new host.
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:
The MX record type is used to specify a mail exchanger for the domain.
The new record now appears in the domain listing.
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:
NOTE: The Microsoft DNS service can be configured to store the boot information in either the boot file, located in the %systemroot%\system32\dns directory or the Registry.
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 |
|---|---|---|---|
| ; | No | Starts 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\DNS | If 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 | Yes | Specifies 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] | No | Specifies 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 |
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 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 | 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 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 |
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.
