Some of the main topics in this chapter are
Name resolution plays a critical role in almost every operation that Windows NT performs; it must be done before you can authenticate to a domain, connect to a server share, or browse a Web site. Name resolution is the process of translating the familiar name for a server--such as AppServer1 or http://www.microsoft.com--to a network address--such as 192.168.100.5--that is recognizable by your network protocol stack.
Prior to Windows NT 4.0, Windows Internet Name Service (WINS) provided name resolution services. With 4.0, you also have the Internet-standard Domain Name Service (DNS) to provide name resolution. This chapter describes when each type of service is required and how best to implement it in your Windows NT environment.
The WINS service is available on Windows NT Server only. During server setup, make sure you install the TCP/IP network protocol. This is required for WINS to install correctly. WINS installs as a Windows NT service, which means it can run regardless of whether or not someone is logged into the server.
Before you install WINS in your Windows NT environment, you need to make some decisions about the role of the server on which you perform the installation. A single WINS server can handle about 10,000 name resolution requests an hour--this is quite significant, and under these loads, you don't want your WINS service running on a server that's also a heavily used primary domain controller (PDC). If you're supporting a relatively small environment (less than 1,000 machines) and there aren't a lot of changes with respect to machines starting up and shutting down, however, you can definitely install WINS on a multi-function server that might also be serving as a domain controller.
Another factor might be the number of WINS servers in your environment. Although it's generally a good idea to plan for as few WINS servers as possible, the greater the number you have, the more you can distribute the load between them and install the service on machines that are performing other roles--such as file and print servers or domain controllers.
CAUTION: Avoid putting your WINS services on servers that regularly perform intensive disk I/O, such as SQL Server-based ones or file servers servicing a large number of clients. These kinds of servers simply slow down the WINS service's capability to scan through its database to resolve names or register addresses. In extreme cases, you might even see the WINS response delayed to the point where the client requesting information times out and has to try another WINS server.
On heavily-used WINS servers, you can use Windows NT's Performance Monitor (PerfMon) utility to track the effect on your server. Specifically, when you install WINS, the setup process adds a new object to PerfMon named Wins Server and its associated counters. You can track Queries/sec to see how many name resolution requests your WINS server is servicing. And, you can match that against CPU utilization on the server, using either the %Processor Time Counter in the Processor object or the wins instance of %Processor Time in the Process object. Based on this information, you can decide if your hardware configuration is sufficient to handle the WINS service load.
To begin, make sure you have your Windows NT Server CD-ROM or the server distribution files available on the server to which you want to install WINS. To install the WINS service on your Windows NT server, add it via the Services tab of the Network Properties dialog box.
After completing the installation of the WINS service, a reference to WINS Manager is placed under Start, Programs, Administrative Tools (Common). The WINS database and associated files are stored on your server's system partition in %systemroot%\system32\wins. The files used by WINS and their functions are described, as follows:
All the files in this directory are critical to the proper operation of WINS, so it's important not to try to delete, modify, or otherwise tamper with them. If you back up your WINS server, make sure these files are included in the backup process. Depending upon your backup software, you might need to stop the WINS service prior to backing up the files to ensure that they're not in use.
After installing the WINS service, all WINS configuration information with respect to push-pull partners, default WINS settings, and replication parameters are kept in the Registry in the HKEY_LOCAL_MACHINE hive. The exact Registry key location is:
\System\CurrentControlSet\Services\WINS
Using regedit or regedt32, you can view this key and its related subkeys. Because all these keys can be indirectly manipulated by using WINS Manager, it's not likely you will ever need to modify them here directly. However, if you ever have trouble loading the manager tool, you can look here to get some basic information about how a WINS server is configured. It's also a good idea to know where the WINS key is in case you need to restore it from a backup after a server failure.
After you install the WINS service, there are several configuration options you need to understand prior to using it in your environment. All configuration options for WINS can be set through the WINS Manager tool. If you have to configure a single WINS server, you can do it either from that WINS server's console or remotely. In the section "Installing and Configuring WINS Manager," you look at configuring the manager tool to control one or more WINS servers remotely.
TIP: If you have multiple WINS servers in your environment, you should set the configuration options identically on each one to prevent unexpected behavior when the servers replicate their databases with each other.
Setting the WINS Options. You access the configuration options in WINS Manager. Choose Server, Configuration from WINS Manager's main menu. Click the Advanced button to open the configuration options for a WINS server.
When you first install the WINS service, you'll see the default values for the configuration parameters. Following is an explanation of each configuration parameter:
A tombstoned or extinct WINS record has a cross next to it.
CAUTION: If you decide to enable the Replicate on Address Change check box, do so only for a limited period of time. If there are many changes happening in your WINS database, this feature causes a lot of additional network traffic and server load. A more efficient way to ensure database consistency among all replicated partners would be to set a very low push Update Count (see the section "Configuring Replication").
Here's a description of the Advanced WINS Server Configuration parameters:
Static Mappings and Imported Host Files. Normally, records are created in the WINS database when devices dynamically register themselves with the WINS server. However, there might be certain machines you want to ensure are always present in the database. An example of this can be a critical Exchange server providing messaging for a key user group or even the PDC for your Windows NT domain. Static mappings are a way to ensure that certain registrations are always in the database.
CAUTION: Static mappings should only be added for a small number of devices, if critically needed. Many static mappings become difficult to manage, cause problems over time if you forget about them, and change IP addressing on statically mapped devices.
You can add static mappings in two different ways: manually or by importing a text file in an LMHOSTS-type format. To access the static mappings feature, start WINS Manager, and choose Mappings, Static Mappings. The Static Mappings dialog box appears (see Figure 14.2).
You can add static mappings from WINS Manager.
If you're adding static mappings manually, click the Add Mappings button, and the Add Static Mappings dialog box appears (see Figure 14.3).
You can add a static record from the Add Static Mappings dialog box.
After you enter the information for Name and IP Address, click Add to add the records to the database. Notice a set of radio buttons on the right side of this dialog box that specify type. Here are the name types WINS supports:
This is an example of using the Internet Group record type to create custom 16th byte types.
If you need to delete a static mapping, you can select the records you want to delete and click the Delete Mapping button in the Static Mappings dialog box. Because each mapping generally creates three different records, however, be careful that you select all records for a given mapping you want to delete. Similarly, you can edit the IP address portion only of an existing mapping by clicking the Edit Mapping button after selecting a record to edit.
If you absolutely have to create a large number of static mappings, you can do so by importing them from LMHOSTS-type files. The LMHOSTS file is specific to Windows NT and 95 and, similar to UNIX hosts files, maps NetBIOS names to IP addresses in a text-file format. The LMHOSTS file differs from UNIX host files in that you can specify NetBIOS-specific information, such as domain name that an entry belongs to or the 16th byte type. To perform an import, start WINS Manager; choose Mappings, Static Mappings; and select Import Mappings. You're prompted for the path to an LMHOSTS file. Choose the path, click Open, and the import process begins. If successful, you receive a message indicating the records were imported successfully.
Listing 14.1 is an example of an LMHOSTS file that can be imported into WINS.
192.168.0.1 ìDOMAINA \0xlbî #PRE #DOM:DOMAINA 192.168.0.1 ìPDC1 \0x1Cî #PRE #DOM:DOMAINA 192.168.10.6 ìBDC1 \0x1Cî #PRE #DOM:DOMAINA 192.168.100.18 ìBDC2 \0x1Cî #PRE #DOM:DOMAINA 192.168.0.1 PDC1 #DOM:DOMAINA 192.168.10.6 BDC1 #DOM:DOMAINA 192.168.100.18 BDC2 #DOM:DOMAINA
The first line of this file imports a lb Unique-type record for the domain called DOMAINA. The next three records import 1C Domain Name-type records for primary and backup domain controllers PDC1, BDC1, and BDC2. The last three records create Unique-type entries for PDC1, BDC1, and BDC2.
For records that contain 16th byte information such as the \0x1C information, you need to ensure that the total length of information within quotes is exactly 19 characters in length, which includes the three \0x characters.
Static records are differentiated from the dynamic WINS when you view the WINS database. From WINS Manager, choose Mappings, Show Database. A checkmark in the S column indicates a static mapping. No checkmark indicates a dynamic entry. The A column indicates that the record is active, as opposed to released or extinct.
Configuring Replication. WINS replication is the process by which multiple WINS servers share their database of registered machine, user, and domain information. If you have multiple WINS servers in your environment and want all WINS-capable clients to be able to resolve all machine names, you need to replicate databases between all WINS servers. This replication process must be configured through WINS Manager's interface. You can set up two types of replication triggers, or events, between WINS servers:
When configuring WINS replication between partners, you need to configure both push and pull replication parameters on both partners.
TIP: WINS partners should always both push and pull replicate with each other to keep the database information consistent. Both push and pull parameters must be identical for a given replication partner.
This is especially true between WINS servers that are acting as primary and secondary WINS servers for WINS-enabled clients. Because a client machine that references two WINS servers in its TCP/IP configuration could register with either server, it's important that both WINS servers replicate each other's database completely. Establishing push/pull replication on both WINS server partners guarantees that this happens. To configure push and pull replication between two WINS servers:
2. The Replication Partners dialog box appears. If the partner's IP address with which you want to establish replication is already in the list, select that entry. If not, click Add to add a new IP address.
3. From the Replication Options frame, mark both the Push Partner and Pull
Partner check boxes. This activates the configure buttons for each.
4. To configure the push update count, click Configure. The Push Partner Properties dialog box appears. Enter a value that represents how many changes can occur in the WINS database before a push trigger is sent. This value depends upon the frequency of changes your database undergoes and how critical it is to keep consistent. Use 20 as a good starting point for most environments. If you've configured a default push value in your WINS manager preferences (see discussion of WINS Manager configuration in the section "Installing and Configuring WINS Manager"), choose Set Default Value to enable those preferences.
5. To configure the pull frequency, click Configure. The Pull Partner Properties dialog box appears. In the Start Time box, enter a time to start the pull replication cycle. Enter the time in hh:mm:ss AM format. For example, to start replication at midnight, enter 12:00:00 AM. Next, choose the replication interval by selecting a time in the Replication Interval (h:m:s) box. This value corresponds to how often this WINS server will send a pull trigger to its replication partner. Again, this value should be identical on both partner servers. As a starting point, select two hours (entered as 02:00:00) as a good interval time. If you've configured a default pull value in your WINS manager preferences, choose Set Default Values to enable those preferences.
6. After you configure both push and pull parameters, repeat steps 1 through 5 on the other WINS server replication partner in this pair.
7. To force a replication immediately, select the WINS server you want to replicate with from the Replication Partners dialog box, and choose Replicate Now to replicate databases between the two partners. You can also selectively send only push or pull triggers between the partners by clicking the Push or Pull button in the Send Replication Trigger Now portion of the Replication Properties dialog box. And, if you mark the Push with Propogation check box and then click the Push button, this WINS server sends a push trigger to all its configured replication partners.
8. Click OK to end replication configuration.
If you have more than two WINS servers, you need to repeat these steps for each replication pair. For a more detailed discussion of WINS replication design, see the section "Creating a Replication Scheme" later in this chapter.
Automatic Replication Using IP Multicasting. There's a little-known feature enabled in WINS servers that you can take advantage of if your network supports IP Multicasting. By default, when a WINS server starts up, it sends an Internet Group Management Protocol (IGMP) packet to multicast address 224.0.1.24. If multicasting is supported on your network, any other WINS servers that receive this multicast automatically configure push/pull replication with that server, as will the server sending the packet. By default, WINS servers that discover each other this way do a pull replication every two hours. When a WINS server service replicating via multicast stops, this partner is removed from all other partners' replication lists. If you manually adjust replication of multicast-configured WINS partners, the replication becomes permanent and won't disappear when the WINS server stops.
Even if your network doesn't support IP multicasting (you operate a routed network and the routers do not pass these packets), you can still see the effects of this replication mechanism if you have two WINS servers on the same physical network segment. They appear to automatically establish replication with each other at startup time.
Configuring Clients to Use WINS. After you install WINS servers in your environment, you need to configure your client machines to take advantage of those servers to perform NetBIOS name resolution. The following steps illustrate how to configure WINS on a Windows NT workstation. Windows 95 is slightly different than Windows NT 4.0 Workstation with respect to configuring WINS.
2. In Windows NT, choose the Protocols property page, and double-click TCP/IP Protocol. If you're configuring Windows 95, choose the Configuration property page, and double-click the TCP/IP Protocol.
3. From the Microsoft TCP/IP Properties dialog box, choose the WINS Address property page to set the WINS references. In Windows 95, choose the WINS Configuration property page.
4. For the chosen NIC, enter the IP address of your Primary WINS Server and your Secondary WINS Server.
NOTE: The distinction between primary and secondary WINS servers is purely logical. You decide which of your WINS servers will be the "primary" and which will be the "secondary" by defining it in the WINS client configuration. Functionally, there's no difference in the WINS server configuration. A client will attempt to contact the "primary" first, when a name resolution is required.
6. Click OK and Close to keep the changes you made to the client configuration. You need to restart the workstation for the changes to take effect.
NOTE: One note about the behavior of WINS clients in Windows NT 4.0--if you start your Windows NT workstation and the primary WINS server it's referencing is down or unavailable, then the secondary temporarily becomes the primary reference. You see the effect of this if you enter ipconfig/all at a command prompt. When the original primary WINS server comes back online, subsequent name resolution requests to the configured IP address find the server available again and restore the original order.
After you install WINS servers, set up replication, and configure your clients to register with WINS, you need to perform ongoing maintenance of the WINS server environment. This becomes especially important if you have a number of WINS servers spread across a WAN environment and potentially have to manage each of them remotely. This section discusses the configuration of the WINS Manager tool, especially as it relates to managing multiple WINS servers. It also discusses the WINS database itself, including how to understand what you see in the database and the management of the data.
By default, WINS Manager is installed to the Start menu of any Windows NT server where the WINS service is installed. It's just as likely, however, that you'll want to run WINS Manager from an administrative workstation and manage multiple WINS servers throughout your enterprise. Follow these steps to install WINS Manager (and other administrative tools) on your Windows NT workstation:
2. Select the folder on the CD named \clients\srvtools\winnt. Launch the batch file named setup.bat. This file copies all necessary server tools, including WINS Manager, to your workstation's system32 directory.
3. After the files have been copied, you have to manually set up shortcuts or links to the application. For convenient access, you might choose to create a shortcut to WINS Manager within your existing Administrative Tools folder or on your desktop. To install WINS Manager as a shortcut on your desktop, place your mouse on a blank part of the desktop and right-click to bring up the Properties menu. Choose New, Shortcut, and in the Create Shortcut dialog box, enter the path to WINS Manager as %systemroot%\system32\winsadmn.exe. Choose Next, and enter a name for the shortcut, such as WINS Manager. The shortcut will then appear on your desktop.
After you install WINS Manager, you can use several configuration options to make the tool easier to use. There are preferences you can set to control how information is presented by WINS Manager, as well as defaults for establishing push and pull triggers with replication partners.
From WINS Manager, choose Options, Preferences to view the configuration screen shown in Figure 14.5.
View the configuration preferences for WINS Manager.
The following list describes the basic configuration options shown in Figure 14.15:
If you choose the Partners button from the Preferences dialog box, you can set the default push and pull replication parameters that are applied to each WINS server you set up through WINS Manager. You can also get basic statistics for the WINS server you're managing from the main window of WINS Manager (see Figure 14.6).
Use the main statistics screen in WINS Manager to view name resolution statistics of the currently managed server.
Here, you can view when the WINS service was started for the chosen server, if the database was pre-initialized by using static data files, the last time the statistics were cleared, and the most recent replication trigger times. You can also see how many queries this WINS server has serviced--successfully and not--and you can see how many records were marked released since the statistics were last cleared.
From WINS Manager's menu, choose Server, Detailed Information to get additional statistics about the managed server, including registration counts for unique and group entries, as well as the last occurrence of database scavenging or removal of records.
Any preferences you configure in WINS Manager are actually kept in your user profile, so they're remembered between logon sessions. You can view these settings by starting the Registry Editor (regedit.exe) from the Start menu and traversing the Current_User hive to the following location: HKEY_CURRENT_USER\Software\Microsoft\WINS Admin Tool.
You can administer multiple WINS servers from a single WINS Manager interface. To do so requires adding the WINS servers you're interested in to WINS Manager's cache, which is simply a list of server IP addresses that appear in WINS Manager's main window.
To add remote WINS servers to be managed, choose Server from WINS Manager's menu, and choose Add WINS Server. You are prompted to enter the IP address for the remote WINS server. Enter the address and choose OK. WINS Manager then attempts to contact the remote server to verify the WINS service is running and to determine the server's machine name. If it finds the server, it will be added to WINS Manager's cache and appear in the list of servers on the main WINS Manager window.
To manage a remote server, double-click the IP address (or name if so configured) of the server of interest. If successful, the statistics screen to the right of the server list are updated with that server's statistics. At that point, you are managing that remote WINS server and are seeing exactly what you would see if you were running WINS Manager from that server's console. This is important to remember. All information you view with respect to configuration, replication partners, and database information is for that remote server. This is true even if you are running WINS Manager from your local WINS server.
To remove remote WINS servers from WINS Manager's cache, highlight the WINS server you want to remove, choose Server from WINS Manager's menu, and choose Delete WINS Server. If you set your preferences to confirm deletions, you are asked to do so. After you delete a WINS server from WINS Manager's cache, you can re-add at any time.
NOTE: Deleting a server from WINS Manager cache has no effect on the WINS services running on that remote server. It only affects what you see on your local manager screen.
There are certain situations in which you might not be able to manage a remote WINS server. To manage any WINS server, you must be logged on using an account that has either Administrator or Server Operator authority. As server operator, however, you can only view and manage the WINS database. You can not change a WINS server's configuration or make modifications with its replication partners.
Note, however, that even as an administrator, you might not be able to connect to certain remote WINS servers. For example, if the WINS servers in your environment reside on servers that are members of Windows NT domains, all the remote WINS server domains must trust the domain in which your user account resides . It is insufficient to explicitly connect as Administrator to a remote WINS server by using a mechanism such as the NET USE command and then expect to manage that server via WINS Manager. This is a limitation in the way WINS Manager authenticates users. It requires a trust relationship to provide pass-through authentication of user credentials from one domain to the next.
After you've configured one or more WINS servers in your environment, machines start registering with them, and replication takes place between two or more of them; you then need to keep an eye on the WINS database. In the desirable fully push-pull replicated WINS environment, you can think of the database as one entity. If you connect to a given WINS server, it should have all the same database records as its replication partner and likewise for all replicating WINS servers. The database on each WINS server is represented as a sum of records owned by each individual WINS server in the environment. The owner of a set of records is the WINS server from which those records originated and were first registered. You can view the entire WINS database and its constituent owners from WINS Manager by choosing Mappings, Show Database.
From the Show Database dialog box, you can view records by the owner who originated them simply by highlighting the correct owner in the Select Owner dialog box, or you can view the entire database regardless of owner by enabling the Show All Mappings option button. In addition, you can change the sort order for viewing the database, and you can set filters to show only records that meet certain criteria. For example, to set a filter to only show only records with an IP address of 192.168.100.1, choose the Set Filter button, and when the Set Filter dialog box appears, enter the IP address and choose OK. The view of the database will change to only show those records that meet the criteria. Click the Clear Filter button to remove the filter and show the entire database again.
In the lower half of the Show Database dialog box, you see the Mappings window, which contains the database records for the chosen owner or the entire database. If you double-click a given record (see Figure 14.7), you can see the type of record it is--in this case, a multihomed one--and if there's more than one IP address associated with the record, you can scroll through the list. Note, however, that you cannot change the record at this point.
You can view the contents of a database record from within the WINS database.
Each record has additional information related to its life in the database:
Understanding Versions. WINS determines what records need to be replicated by comparing the version of the database on one server with its version on another. By default, when a new WINS server is created, the first record that registers with it starts at version 0. Each subsequent record that registers with the database is assigned a version number. The version number is 2 bytes long, and contains a low order and high order value. Unless your database is very large, you only see the low order value. The high order value is generally 0. Database records are assigned sequential version numbers, one after another.
If 10 records register in a WINS Server called Server1, the 10th record has a version number of A, which is 10 in hex notation. At that point, the database is said to be at version number A. If the database then replicates these 10 records with a partner called Server2, the partner has the version number of A for records owned by Server1. Later, if five more records register with Server1, its new version number will be F. When Server2 reaches its pull interval with Server1, it compares the version number it has for records in its database owned by Server1 with what is currently on Server1--which are all records between A and F. These are the records that are replicated.
Suppose, however, that an existing record at version 4 on Server1 is not renewed and is eventually released from Server1. How is that release propagated to Server2? In effect, in doesn't have to. The Expiration Date assigned to that record from Server1 is carried over to Server2. When the time on Server2 reaches the expiration date, the record is released. This makes it important that you have the system clocks on all your WINS servers relatively closely synchronized. WINS servers that are badly out of synch can cause records to not be released, or in the worst case, where Server2's clock is out of synch with Server1 by a number of days exceeding the Renewal Interval, the record is never even replicated.
TIP: All WINS servers within a replicated environment should have their system time synchronized to ensure accurate record aging.
Understanding 16th Byte Values. You've noticed the hex characters at the end of each WINS record. These are specific to the NetBIOS protocol and indicate the function of that particular record. They are called 16th byte values because they always occupy the 16th byte of any NetBIOS name. For this reason, a NetBIOS name can be only 15 characters long. Shorter names are padded up to the 16th byte. Windows NT uses the 16th byte type to identify many NetBIOS specific functions by name. Because Windows NT and Windows 95 machines, logged-on users, and domain controllers all register information with WINS, there are several different categories of 16th byte values, as explained in Table 14.1.
| Device Name and 16th Byte Value | Usage |
| <domain_name>[1Dh] | Name of the Domain Master Browser. |
| <domain_name>[1Eh] | Name used by browsers to elect a Master Browser. |
| <domain_name>[00h] | Name registered by the Workstation service on the domain controller to receive browser broadcasts from LAN Manager servers. |
| <domain_name>[lbh] | Name registered by all domain controllers in a domain. |
| <domain_name>[1Ch] | Name registered by all domain controllers, which can contain up to 25 IP addresses of other domain controllers. This group is used to provide a client with a list of domain controllers that can authenticate its logon request. |
| <user_name>[03h] | Name that registers logged-on users for net send operations. |
| <computer_name>[00h] | Name registered by the Workstation or Redirector Service on this computer. |
| <computer_name>[03h] | Name registered by the Messenger Service on this computer, which is used to issue a net send command to a machine name. |
| <computer_name>[+++nnh] | Name used by the Network Monitoring Agent when it's installed on this computer (nn indicates any hex value). |
| <computer_name>[1Fh] | Name registered by the NetDDE service on this computer. |
| <computer_name>[20h] | Name registered by the Server service on this computer. |
As an example of how 16th byte values are used, when a WINS-enabled Windows NT workstation that is the member of a domain first starts, it queries its configured primary WINS server for a list of available domain controllers for the domain of which it is a member. To perform this query, it goes to the WINS database and requests the multihomed 1Ch type record for the domain name it belongs to. Similarly, if you want to send a net send message to a user on the network, your client queries WINS for the user's name with a 03h value to determine the IP address where the user is currently logged on. The message is then forwarded to that machine.
Compressing the Database. Prior to Windows NT Server 4.0, you had to perform periodic manual maintenance on the WINS database. This maintenance came in the form of running the jetpack utility on the database to re-write, and therefore compress, the database. In Windows NT 4.0, the WINS service now performs auto-compression of the database on a periodic basis. You still can use the jetpack utility to manually compress the database, however, if you choose to do so. If the wins.mdb file in the %systemroot%\ system32\wins folder ever grows more than 30M, it should be jetpacked. To run the jetpack utility:
2. From the Start menu, choose Programs, MS-DOS Command Prompt to bring up a command shell.
3. Type cd %systemroot%\system32\wins and press Enter.
4. You need to stop the WINS service to perform the compression. Type net stop "Windows Internet Name Service" and press Enter.
5. Jetpack the database by typing jetpack wins.mdb winstmp.mdb, where winstmp.mdb is a temporary file used for re-writing the database.
6. Upon successful completion, restart the WINS service by entering net start "Windows Internet Name Service".
Deleting Records from the Database. You might come across a circumstance in which records in your WINS database have become corrupted. This usually manifests itself as strings of garbage characters showing up as registered records. Unfortunately, there is no easy way to remove individual records from a WINS database. The easiest way to remove corrupt entries is to first locate the server that owns the corrupt records.
You can eliminate the records in a couple of ways. First, the records need to be removed from the source database; otherwise, they'll continue to replicate. For example, if WINS server A owns a corrupt record and replicates it to WINS servers B and C, you must first remove the corrupt record on A to ensure that it does not continue to replicate after being removed from B and C. From WINS Manager, you cannot remove an individual record. Rather, you have to delete the owner of that portion of the database that is corrupt. This might seem extreme, but with the normal tools available, this is the only way to get at the corrupt records. (The next section shows how to use the winscl command-line tool that comes with the Resource Kit. This tool enables deletion of individual records in the database.)
In our example, if server A owns the corrupt record, you need to delete the records on server A, owned by itself. This means that all machines and users that registered with server A will lose their registrations. As a result, you should perform this operation during off hours. Also, prior to deleting the owner of these records, you should disable replication with all of server A's replication partners. This is because the Delete Owner operation automatically sends a replication trigger to all of A's partners, which would result in the partners re-replicating A's own corrupt records back to it. To delete the owner of a set of database records, start WINS Manager and choose Mappings, Show Database. From the Show Database dialog box, highlight the IP address of the owner of the records to delete. Then select Delete Owner.
After you've deleted the owner of the corrupt records on server A, those records are no longer in the database on that server. However, you then have to peform the delete owner operation for the records owned by server A on all its replication partners. Finally, you can re-establish the replication of A with all its partners.
Another alternative in dealing with corrupt records is to restore the database from a backup prior to when the corruption occurred. See the section "Backing Up and Restoring the WINS Database" for information on restoring the database from a backup.
Using WINSCL. In the Windows NT Server 4.0 Resource Kit, there's a command-line tool that you can use to manipulate the WINS database at a more granular level. It's called winscl for WINS command-line and provides a host of functions to manipulate WINS databases, both locally and remotely. winscl performs every function from issuing a replication trigger to deleting owner records from a database. Figure 14.8 shows the list of commands available.
This is a list of the available commands in the winscl tool.
Because the winscl tool is a Resource Kit utility, it's not very well documented and can perform in odd ways. For example, the commands you provide are case-sensitive. Also, after you perform an operation, the status code usually scrolls by so quickly that you don't have a chance to view it. It can be useful, however, for manipulating individual WINS database records. The following steps describe the tasks you would perform to delete a record from a WINS server's database.
2. You receive the following prompt:
TCP/IP or named pipe. Enter 1 for TCP/IP
3. You're then prompted for the WINS name server to which you want to connect. Enter the IP address of the WINS server that contains the record to delete, and press Enter.
4. After the IP address is entered, a list of available commands scrolls across the screen. To delete a record, enter DRR (Delete all or a range of records) at the command prompt. Note that this command must be in capitals. Next, you're prompted for Address of Owner WINS. Enter the IP address of the owner of the record on this server you want to delete.
5. You are then prompted to enter the low end of the version number range you want to delete:
Min. Vers. No (<high part> <low part>) --
Earlier in the chapter (see "Setting the WINS Options"), we discussed several configuration options that enable you to back up the WINS database each time the service terminated, as well as perform periodic backups. Last, you can back up the database explicitly from WINS Manager and restore it as well at a later time. To back up and restore the WINS database, start WINS Manager and follow these steps:
2. Choose either a new or existing directory name for the backup files. The backup process creates a subdirectory called wins_bak, and places the backup files in a subdirectory under that called new.
3. If the backup completes, you see an on-screen message indicating a successful backup.
4. To restore the database, you first need to stop the WINS service by issuing a net stop "Windows Internet Name Service" command from the command prompt (You can also stop the service from the Services applet in the Control Panel). Then from WINS Manager, choose Mappings, Restore Local Database. You are again prompted for the path to wins_bak you created in Step 2. Enter the path, and choose OK. The restore process places the backed-up files in the %systemroot%\system32\wins folder.
5. At this point, you can restart the WINS service by typing net start "Windows Internet Name Service" at the command prompt (or from the Services applet in the Control Panel).
Beyond these methods, it's always a good idea to back up the files on your server, including the WINS database files, to either tape or other storage media besides the server's hard drive. One easy solution if you have multiple WINS servers is to periodically copy the contents of the %systemroot%\system32\wins folder to a backup folder on another WINS server, such that each WINS server holds the backup of one of its partners.
See "Applying Backup Strategies," p. 510
You've looked extensively at how to build and manage a WINS server. Now learn how to design a WINS deployment that meets the dual needs of providing a robust name resolution service and a supportable infrastructure. The dynamic nature of WINS is both a benefit and a disadvantage. It's a benefit because it doesn't require manually adding machine names and IP addresses to static LMHOSTS files. But it's a disadvantage because you don't have absolute control over what's being registered with the database. As an added challenge, in a multiple WINS server environment, you have to contend with replication problems and potential corruption of the database. To counter these effects, the best deployment goal is to keep things as simple as possible.
When deciding how many WINS servers to deploy, your end goal should always be to deploy as few as possible. As the number of servers increases so does the complexity in terms of replication and management of the database. Remember that WINS is providing name resolution services for machine-to-machine connectivity, as well as domain authentication information and other Windows NT-specific functions. In a TCP/IP Windows NT, WINS is critical to performing many tasks.
A robust WINS server design should balance the issues of server load, network availability, and manageability. Unless you have a very small environment (50-100 clients), two WINS servers should be the minimum deployment. This provides some load balancing and fault tolerance in the event that one server fails. If you have fewer than 5,000 client machines in a centrally located LAN environment, you can easily provide robust name resolution services with two WINS servers that push-pull replicate with each other. If your user population is much bigger or more widely separated, you have to consider additional WINS servers. Although it's not necessary (or even desirable) to deploy a WINS server at every remote location, you need to balance response time for your client machines with replication and management of many more servers.
For example, in a branch office environment, you might have many small offices located across slow WAN links from your main headquarters location. In this case, it probably makes sense to keep the WINS servers centrally located at your headquarters. Figure 14.9 shows an example of a WINS deployment that accommodates both branch office users and regional headquarters users.
In Figure 14.9, there are two WINS servers in the Headquarters location--logically assigned primary and secondary. Each branch office client, located across a slow (56Kbps) WAN link, uses these two WINS servers for name resolution. Additionally, there is a regional office connected to the Headquarters via a fast WAN link (T1). This regional office has its own primary WINS server that provides local name registration and resolution. However, the clients also reference one of the WINS servers in Headquarters as their secondary. The two primary WINS servers perform push-pull replication with the one secondary, guaranteeing that all WINS servers contain the same database information.
This is a design for a WINS servers deployment in a branch office environment.
Microsoft estimates that a WINS server can handle about 10,000 name resolution requests an hour. By using the statistics available in WINS Manager, you can keep track of the load on your WINS servers and add more as needed (always with the goal in mind to have as few WINS servers as possible). Remember that load on the server increases when users restart their machines and perform name registration. If this happens at the beginning of every day, your server needs to be able to handle that peak load. It's a good idea to install WINS on a Windows NT server that is doing little else, especially if you are expecting it to accommodate thousands of clients. For example, you might be able to successfully install WINS on a BDC if your client population doesn't grow too large. If in doubt, it's safest to just install WINS on a non-domain controller member server.
One last issue relates to WINS and multihomed servers--servers with multiple NICs. In past versions of WINS, it has been difficult to configure WINS to perform effectively on a multihomed server. In Windows NT 4.0, it works better, but is not recommended. If you're trying to increase bandwidth into the server, consider using a single high-speed NIC (100BaseT or FDDI) or employ switching technology to maximize available bandwidth to the server.
The key to creating a successful replication scheme, just as when you're designing a network routing plan for your network, is to avoid loops. For example, if WINS server A push-pull replicates with WINS server B, which push-pull replicates with C, you have a complete replication pattern, where all database information is replicated to all servers. However, if you were to add a push-pull replication between C and A, you would have a replication loop (see Figure 14.10), which can be difficult to troubleshoot when replication problems occur.
This is a WINS replication design that creates a replication loop between WINS servers.
It's important to always have an end point to a given replication path. That is, if you follow the path of replication from each and every server in your WINS environment, each one should terminate at some point. If you find yourself following replication around and around, you have a loop. Figure 14.11 shows a replication design with multiple WINS servers in which each terminates at a central "hub" server.
In this configuration, client PCs would point to their local WINS server as the primary, and the central hub server as their secondary. All WINS servers would have a complete database containing the records owned by every other WINS server. In this kind of configuration, it's much easier to detect and solve replication problems. If you break replication at any of the outside primary servers, that server is effectively isolated and lends itself to easier troubleshooting.
The Windows NT DNS service runs--just as WINS does--as a service on your server. It's also only available with Windows NT Server. The TCP/IP protocol must be installed prior to installing the DNS service.
This is a design for a non-looping WINS replication scheme.
The following sections step you through the installation and configuration of DNS to implement it in your TCP/IP-based Windows NT environment.
To begin, make sure you have your Windows NT Server CD-ROM or the server distribution files available on the server you want to install DNS to. To install the DNS service on your Windows NT server:
2. Select the Services property page, and choose Add. From the Select Network Service dialog box, use the scroll bar to select Microsoft DNS Server and choose OK.
3. The Windows NT Setup dialog box appears and prompts for the location of your Windows NT Server CD-ROM path or distribution source. Enter the path and platform-type (Intel servers enter d:\i386, where d is the CD-ROM drive) and choose Continue. Setup then copies the needed files for DNS.
4. When finished, choose Close to update the network bindings. Choose Yes to restart your server so that the WINS changes can take effect.
After completing the installation of the DNS service, a reference to DNS Manager is placed in the Start menu in Programs, Administrative Tools (Common). To remain RFC-compliant, the Microsoft DNS service uses the same text file format that you find on UNIX-based DNS servers. DNS Manager, however, provides a nice, easy-to-use administrative front end to these text files.
If you're familiar with the direct manipulation of text files from managing a UNIX-based DNS service, you can also manipulate the DNS configuration files directly in Windows NT. By default, the DNS files are stored on your server's system partition in %systemroot%\system32\dns. Information about the DNS configuration, DNS zones, and boot information for the service are, by default, stored in the Registry in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services|DNS.
In the %systemroot%\system32\dns folder, you'll find two other folders. The first, named samples, provides you with some sample configuration files and a sample boot file. The boot file can provide DNS configuration information at the time the DNS service starts. By default, however, the DNS service uses the Registry for this information unless you explicitly use a boot file to configure DNS. The reason the boot file is available in the first place has to do with providing ease of integration with existing BIND-based DNS implementations in your environment. If you decided to port all your DNS services from a UNIX-based system to Microsoft DNS, you could take the UNIX boot files and use them to boot your Windows NT DNS service.
The other folder, named backup, provides a backup location for configuration files.
As with WINS, the type of Windows NT server you use for DNS services depends upon what kind of load you expect to experience. If you're installing a DNS server to provide name resolution services for potentially thousands of Internet clients, you'll want to dedicate one or more servers to providing DNS services only. In this case, these machines should not be installed as domain controllers but rather as regular Windows NT member servers. If you're installing the DNS service to provide internal DNS and WINS integration to relatively few non-WINS clients in your enterprise, however, you'll generally be able to run DNS on a machine that performs other tasks, such as a BDC or even a WINS server. There are no restrictions against running the DNS and WINS services on the same server.
Unfortunately, there are no PerfMon counters to keep track of the number of name resolution requests or other activity that the DNS service is performing. However, you can view some basic statistics from the main DNS Manager screen to see what kind of load your DNS server is servicing.
Configuring DNS is a bit different than configuring WINS. Because DNS information is not dynamic like WINS, you have to enter all host information manually. Additionally, just as with WINS and its different 16th byte values, there are different kinds of records that DNS requires to operate. We'll look at some of the more common types in the section titled "Resource Record Types," as well as examine the different roles a DNS server can play. Most of the configuration work you do will take place in DNS Manager. From here, you can add records, create new domains, and configure replication with other DNS servers.
Before you learn how to configure DNS servers, we need to define a few terms to help you understand how DNS works:
Server Types. In the MS-DNS service, you can configure servers to perform four different functions:
A given DNS server can be a primary for some zones and a secondary for others.
Resource Record Types. Just as in WINS, with its different 16th byte values that correspond to different NetBIOS functions, so DNS has different types of records. The DNS Resource Record (RR) types correspond to different functions that the record fulfills. There are 16 RRs supported in Microsoft's DNS service, but you probably will only use about eight of them. The most popular ones are described here:
Creating Domains and Subdomains. The first and most basic operation you'll want to perform is the creation of a domain. You've installed the DNS service on your server, and you want to build a domain for your company. Assume for now that your domain won't be connected to the Internet. Use the following steps:
2. You see your server appear in the main server list window. Double-click the server to access a listing of the zones that have been created automatically. You should see a cache file and a number of reverse-mapping zones with the suffix in-addr.arpa. If you don't see the reverse-mapping files, choose Options, Preferences from DNS Manager's menu; in the Preferences dialog box, mark the Show Automatically Created Zones check box. Click OK.
3. Highlight the server's IP address. To add a new domain, either choose DNS, New Zone or right-click the server and choose New Zone. The Creating New Zone dialog box appears to guide you through the process of creating a zone file. If this is a zone file for a new domain, it has to be a primary. Select the Primary button, and click Next.
4. Enter the zone information. In the Zone Name box, enter the name of the domain you want to create. In Figure 14.12, this is mycompany.com. If you tab to the Zone File, the zone file name is automatically added for you. The name is simply your domain name followed by the .dns extension. Click Next.
5. Click Finish to complete the creation of the zone file and the new domain. From DNS Manager, you can see the new domain appear in the list. If you highlight the domain, you can see that three records were created for you in the domain--an NS, an SOA, and an A.
6. To create a subdomain under mycompany.com, highlight mycompany.com and repeat steps 3-5.
Enter the Domain Name information to create a new zone.
When you first started DNS Manager, you noticed several zones that were created automatically as part of the DNS install process. We already talked about reverse-mapping zones such as 0.in-addr.arpa. There's also a cache zone which serves a very important purpose. The cache zone holds information related to all root domains on the Internet. If you double-click the Cache icon in DNS Manager, you see two entries underneath it. The first, arpa, holds information related to reverse-mapping zones on this server. The second, NET, holds a list of all root servers on the Internet (see Figure 14.13).
View the list of Internet root servers in the DNS cache file.
The Cache file acts just as its name implies. It's a cache of names resolved by this DNS server. If the names exist in zones defined on this server, such as mycompany.com, then the information in those zones is automatically added to the cache. If the name is resolved by another server, however, as the result of a request by this server, the name is also kept in the cache file. Subsequent requests to that name will be resolved out of the cache, resulting in quicker name resolution.
After creating mydomain.com, there are several parameters that you need to be aware of related to the domain. From DNS Manager, highlight mycompany.com, right-click, and choose Properties. The Zone Properties dialog box appears and shows a number of property pages, described as follows:
View the available properties for the SOA record in DNS Manager.
Table 14.2 describes the parameters on the SOA page.
| Parameter | Description |
| TTL | Time-to-Live; indicates how long this zone can be cached by a DNS server that has requested its information. This information is sent whenever request is received by this zone. By default, it is set at 60 minutes. |
| Primary Name Server | Simply the name of the server that is authoritative for this zone. |
| DNS Name | |
| Responsible Person | The SMTP e-mail address of the person responsible for this domain. |
| Mailbox DNS Name | It is shown in the form administrator.mycompany.com, but it corresponds to the e-mail address administrator@mycompany.com. |
| Serial Number | The number used to determine whether changes have occurred between the last replication to a secondary and now. It's very similar in function to the WINS version number. This number is automatically incremented when you add records to the zone, and it can be manually adjusted, as well. |
| Refresh Interval | Determines how often a secondary should poll the primary to determine if the primary's serial number has changed and new information should be pulled. |
| Retry Interval | Tells a secondary how often to retry if, after the refresh interval expires, the secondary fails to contact the primary. |
| Expire Time | If the secondary cannot contact the primary after the expire time has elapsed, then the secondary stops trying and marks its information for the zone as expired. |
| Minimum Default TTL | Indicates what the minimum TTL should be for this zone. |
Creating Reverse Mappings. Reverse mappings can be confusing. It's important to remember that you aren't required to build a reverse-mapping file. If you're providing DNS services for UNIX hosts, it's probably a good idea because many UNIX functions such as NFS use reverse-mapping information as a kind of security verification mechanism--albeit a fairly weak one.
Reverse-mapping zones need to be created for every major IP network address in your environment. If you've subnetted your network, you should create individual zone files for each subnet. This keeps the size of your reverse-mapping files more manageable. In the example of creating mycompany.com, we set the primary name server for that domain to servera, which has a Class C IP address of 192.168.200.1. The network portion of this address--192.168.200--forms the basis for a reverse-mapping file called 200.168.192.in-addr.arpa.
NOTE: The octets of the address are reversed because we're interested in the network portion of the address and it's more efficient to read it right-to-left as opposed to the normal left-to-right.
The following steps explain how to create a reverse-mapping zone in DNS:
2. In the Zone Name field, enter the name for this reverse-mapping zone. In our example, we are adding a zone for the Class C 192.168.200.0 network. So, in the Zone Name field enter 200.168.192.in-addr.arpa. If you tab to the next field, the zone file name is automatically entered. Click Next.
3. Click Finish to complete the zone creation. The new zone appears in the server list and contains NS and SOA records, just as the mycompany.com domain.
You can now add reverse-mapping PTR (pointer) records to these zone files. The creation of PTR records can be automated when you create their corresponding A record.
Creating Address Records and Aliases. Microsoft's DNS Manager makes it simple to create A, PTR, MX, and CNAME records in a given zone. The following steps show how to create these records in our previously created mycompany.com domain:
2. To create a record other than an A type, highlight the zone under which you want to create a new record, right-click the domain name to bring up the menu, and choose New Record. The New Resource Record dialog box appears, where you can choose from a number of options.
3. For the example, add both an MX and a CNAME record. Create a CNAME of www for the A record Webserver just created. From the New Resource Record dialog box, scroll the record type to CNAME, and highlight that choice. Notice the entry fields change to support entering an alias. First, enter the alias name--in the example, www. Next, enter the server name that you're aliasing in the For Host DNS Name field. If you want to adjust the TTL for this record, you can. Click OK to add the CNAME record.
4. Add the MX record. Again, highlight the mycompany.com zone, right-click to bring up the Options menu, and choose New Record. From the New Resource Record dialog box, scroll the record type to MX, and highlight that choice. Notice that the entry fields change to support entering mail exchange server. You can optionally enter a host name for this server that is appended to the domain name. For example, you might enter mailhost to indicate that it's a mail server.
Next, enter the FQDN of the server that is to provide mail services. In the example, that's servera.mycompany.com.
Finally, enter a preference number from 0 to 65535. This number is used if you have multiple MX records in a domain. The record with the lowest preference number handles mail first, followed by the next highest. Figure 14.15 shows the completed record.
Figure 14.16 shows the mycompany.com domain with all the records added.
Add an MX record to the domain for SMTP mail delivery.
This is the mycompany.com zone with all the records added.
Configuring Secondaries and Zone Transfers. A zone
transfer is the process by which a secondary DNS server for a given zone polls
a master--which can be either a primary or another secondary--to determine
if there are new records for that zone. If so, it asks the master to transfer the
new zone information to the secondary. The secondary holds what amounts to a read-only
copy of the zone and can provide name resolution for that zone just as the master
does. To configure a secondary zone for zone transfers with a master:
5. After creating the secondary, you need to add an NS record for this new secondary to the primary's zone file. That is, if you've added a secondary on a server called servera.mycompany.com to the zone isp.net, then on the primary server that's authoritative for isp.net, create an NS record for servera.mycompany.com.
After you've configured the secondary, it polls the master at the Refresh Interval defined in the SOA record on the master. This is 60 minutes by default. If the serial number of the SOA record on the master is greater than that of the SOA record on the secondary, the secondary requests a zone transfer. The zone file is then pulled down to the secondary and it has up-to-date information. As discussed earlier in the section on "Creating Domains and Subdomains," it's also possible to have the master notify the secondary at specific intervals to keep the secondaries more quickly synchronized.
NOTE: We've been discussing zone transfers between Windows NT DNS servers, but it's also possible to implement a zone transfer between a UNIX primary and a Windows NT secondary, or vice-versa, assuming the UNIX box is using a compatible BIND implementation. You need only define the Master or Secondary as a UNIX host name instead of a Windows NT one. Be aware that UNIX does not support the WINS and WINS-R resource record types, however, so Windows NT zones containing these references cannot be transferred between UNIX zones. Because implementations of BIND vary and are updated frequently, the best way to determine compatibility in your environment is to set up a test zone transfer between your Windows NT and UNIX DNS servers.
Integrating DNS and WINS. The Microsoft DNS service provides two special RRs--WINS and WINS-R--for use with WINS integration. The focus of the DNS integration with WINS is that for non-WINS clients: Like a UNIX workstation, you need a method for resolving WINS-registered NetBIOS names. Rather than statically enter the names and IP addresses of all your NetBIOS machines in DNS, these two RRs provide a way to pass through name resolution requests from a DNS to WINS.
Say you want to ping a Windows NT workstation called ws1 to see if it's alive, but you don't know its IP address. If the UNIX workstation where you issue the command is configured to resolve names from a MS-DNS server, then the request goes to the server, and the server makes an attempt to resolve it for the workstation's domain name. If ws1 is not in the zone file, the DNS server looks to see if it has a WINS resource record. If so, the server queries the specified WINS server for the name. If the WINS server has ws1 registered, it passes the name and IP address mapping back to the DNS server, which responds to the UNIX workstation's request. The WINS name is also placed in the cache file for that zone on the DNS server.
Similarly, for reverse mappings, you can create a WINS-R resource record on the MS-DNS server. If a non-WINS client tries to resolve an IP address to a host name, the DNS server's reverse-mapping zone file for that address tries to locate the record locally. If not found, then it uses the WINS-R record to go to the specified WINS server and tries to locate the NetBIOS name associated with the address.
Configuring DNS for WINS Name Resolution. You've seen examples of WINS and WINS-R type records when creating zone files. To explicitly create a WINS or WINS-R record in a zone:
2. Right-click the zone and choose Properties from the Options menu. From the Zone Properties page, choose WINS Lookup (or Reverse WINS Lookup from a reverse-mapping zone).
3. Mark the Use WINS Lookup (or Use Reverse WINS Lookup) check box to enable the WINS lookup. Next, enter the IP addresses of the WINS server(s) you want for the lookup. If you're creating a reverse WINS record, you need to enter the DNS Host Domain to be appended to the NetBIOS name that WINS provides. If you're defining WINS records on a primary, you can mark the Settings Only Affect Local Server check box. Normally, when WINS resolves NetBIOS names , they are added to the zone file as A records. If you mark this check box, however, these WINS records are not replicated to any configured secondaries.
Click Advanced to modify the Cache Timeout value, Lookup Timeout, and for forward mappings, the NetBIOS scope information. The Cache Timeout value indicates how long the WINS response should be kept in the DNS cache file and defaults to 10 minutes. The Lookup Timeout indicates how long the DNS server should wait to receive a response from WINS before either trying another WINS server or failing.
4. After you complete the configuration of the WINS lookup, click OK to add the record.
The maintenance of the MS-DNS server is fairly straightforward because, unlike WINS with its proprietary database, the DNS configuration files are simply text files that can be edited with a text editor like Notepad. No compression of files needs to be performed. Backing up DNS files is simply a matter of copying the contents of the %systemroot%\system32\dns folder to another location. The Registry entries for the DNS Server service can be backed up, as well and restored if needed.
When you make changes through DNS Manager's interface, the changes are not immediately written to the data files on disk. To perform this flushing of changes, simply right-click the IP address of the DNS server, and select Update Server Data Files. At that point, the files in %systemroot%\system32\dns reflect what you see in DNS Manager.
DNS Manager can be used to perform all operations related to the MS-DNS server. It's installed by default on the DNS server but can also be installed on a Windows NT 4.0 workstation for remote administration. Unfortunately, DNS Manager's executable, dnsadmin.exe, is not one of the utilities installed from the srvtools folder on the Windows NT 4.0 CD-ROM. To install the utility on your Windows NT 4.0 workstation, copy the dnsadmin.exe file from the %systemroot%\system32 folder on your DNS server to %systemroot%\system32 on your Windows NT 4.0 workstation. You then can create a shortcut to start the executable and can add servers to manage, as needed.
Administering remote DNS servers is simply a matter of adding servers to the server list in DNS Manager. Highlight the server list icon; choose DNS, New Server; and enter the IP address of the remote server you want to manage. It's that simple. If you double-click the new server, you see all the zone information related to that server and can add and delete records just as if you were at the server's console.
nslookup is a command-line utility that's useful for gathering information about DNS servers. It's a standard DNS tool provided in Windows NT 4.0 Server. You can use it to connect to both Microsoft and UNIX-based DNS servers and query them for information. Figure 14.17 shows the commands available with nslookup.
To use the command, type nslookup <ip address> from the command prompt, where <ip address> is the address of the name server you want to query. After you connect to the name server, you receive a > prompt. From this prompt, you can enter commands to get information about the server. For example, suppose you want to know if there's a record for a host named Webserver. At the > prompt, type webserver. You see the following response:
> webserver Server: servera.mycompany.com Address: 192.168.200.1 Name: webserver.mycompany.com Address: 192.168.200.20
These are the commands available with the nslookup command-line utility.
The address for Webserver is 192.168.200.20, and the DNS server you're connected to is servera.mycompany.com.
You also can examine other types of records within a DNS server. For example, suppose you want to see the SOA record for the zone mycompany.com. At the > prompt, enter ls -t SOA mycompany.com. This command says, "List all records of type SOA for the mycompany.com zone." The response looks like this:
> ls -t SOA mycompany.com [servera.mycompany.com] mycompany.com. SOA servera.mycompany.com administrator.mycom pany.com. (3 3600 600 86400 3600) mycompany.com. SOA servera.mycompany.com administrator.mycom pany.com. (3 3600 600 86400 3600)
The numbers in parentheses represent the various configuration values associated with SOA records (Refresh Interval, Timeout Interval, and so on).
To exit nslookup, type exit, and press Enter.
Deciding on a DNS deployment strategy is almost identical to designing a WINS deployment. You need to balance network throughput, client responsiveness, and manageability. Additionally, because DNS is hierarchical, you can delegate management of individual zones to other administrative authorities. This dictates how many DNS servers and where they're placed in your environment. Additionally, if you plan to integrate DNS and WINS, the DNS that needs to talk to WINS should be located near the WINS servers to ensure speedy name resolution between the two spaces.
The number of DNS servers you deploy also depends upon your enterprise needs. Because you have a few different kinds of DNS servers available, you might end up deploying more than you would in a WINS environment. For example, at remote sites, you might consider deploying a caching-only DNS server that does not participate in high-bandwidth zone transfers but does keep resolved names cached locally for clients. In environments of more than 50-100 clients, you always want at least two DNS servers providing name resolution for a given zone. The primary can be running on a server that does other tasks, such as a domain controller, and you can set up a secondary that pulls zone information from the primary. Your DNS clients can then be configured to use the secondary for most of their name resolution requests, falling back to the primary in the event of failure on the secondary.
In large environments, with thousands of clients, you'll probably want more than two servers providing services for a given zone. In fact, you probably won't want the same server to be authoritative for all zones. You might have two servers that share primary responsibilities for all zones. You might then have another tier of secondaries to those primaries and still another tier of secondaries that get their zone information from the second-level secondaries.
This design provides a mix of fault tolerance and load balancing and relieves the primaries from having to perform any client name resolution. This kind of design is also useful if you have centralized administration of DNS servers but have remote users that require DNS services. The primaries can be located local to your administrators, but either the first- or second-level secondaries can be distributed throughout your remote sites.
© Copyright, Macmillan Computer Publishing. All rights reserved.