Name resolution is an element of a network that can make a network administrators job ten times easier. If you are familiar with the Internet or TCP/IP concepts, you should already know what name resolution means. But, to be certain, this chapter covers this topic from the basics on up so forgive me if I cover topics that are already well known to you.
Name resolution is the action of translating a written, alpha-type Internet address (like pandy.com) into the actual TCP/IP numeric address (like 198.144.70.211). Of the two, the numeric address is the more important, though humans tend to have a problem remembering only numbers. The written form of an Internet address is only a convenience address. A network can operate via the TCP/IP protocol completely without name resolution or it can have some service available that performs the act of translating an alpha name to an actual IP address. On a Windows NT 4.0-based network, two main methods of name resolution can be implemented to take care of this need. These two methods are WINS (Windows Internet Name Service) and DNS (Domain Name Service). Either of these services may be present on an NT network, or both can run parallel to each other to handle a wide range of needs a network might have.
This chapter will not cover how to completely set up a WINS and/or DNS server, but it will cover the two topics sufficiently to allow you to set them up to handle basic network client name resolution needs.
Imagine this scenario. You are the network administrator of a 100+ workstation network. For your Internet needs, you are using Microsoft Proxy Server so that network users can have external access to your ISDN link to the Internet. Figure 9.1 diagrams this example.
The following elements are in play:
Any other network information is unnecessary for this example. Make sure you have a good grasp of Figure 9.1. This figure shows only seven workstations, though I'll refer to the network as having more than 100 workstations.
Without any name resolution service available on this network, the network administrator must hard code the IP address location of Microsoft Proxy Server into each workstation. This could include several configurations on each workstation, depending on what Internet applications the workstations have installed. For example, Netscape Navigator does not follow any of the Internet settings made through the Internet control applet found in the Control Panel of Windows 95. Netscape Navigator utilizes its own internal configuration for addressing a proxy server. All Microsoft Internet applications, however, will follow the settings in the Internet section of Control Panel. If users use both Internet Explorer and Netscape Navigator, that means at least two separate configurations have to be dealt with.
Should the IP address location of Microsoft Proxy Server change on this network, the network administrator has a two- or three-day project altering all workstations on the network to see the new IP address. What is much more convenient is to let the name of the Microsoft Proxy Server machine control the location. The name used for resolution purposes can be the actual name of the Microsoft Proxy Server machine (which is not advised), or it can be a name created on the name resolution servers to stand for Microsoft Proxy Server.
Let's take for example the name "Proxy_Server". An entry of "Proxy_Server" in the name resolution service can be used to reference the IP address 192.168.100.3Ñthe IP location of Microsoft Proxy Server. The name "Proxy_Server" can be added to the WINS of DNS databases as a static name. Which name resolution service workstations will use depends on what form of name resolution workstations can perform. When workstations resolve the name "Proxy_Server", they'll find out from the name server what IP to access for proxy access. In order to make network-wide changes to the proxy server location, all the network administrator has to do is alter the name server database entry for "Proxy_Server" and all network clients will begin to access the proxy server at the new IP address without having to do any reconfiguring.
Keep in mind that WINS name resolution is only supported in Windows environments. Macintosh, UNIX, and OS/2 operating systems do not support WINS name resolution of any kind. DNS, on the other hand, is universally accepted by all operating systems as a basic component of the TCP/IP protocol. Windows NT 4.0 can run both a WINS server and a DNS server in tandem, both working together to resolve any and all name resolution requests that come from any client. Many third-party DNS servers are now available for NT. However, only the built-in DNS server that comes with NT 4.0 has the ability to reference a WINS server if it gets a name resolution request it cannot handle.
Herein is the real beauty of NT 4.0 name resolution. To be quite honest, configuring a DNS server is a real pain unless you are a long time UNIX guru and understand all the non-intuitive terms involved with DNS. With NT 4.0, you can use WINS for nearly all your name resolution needs and simply tell your DNS server to reference the WINS server for all requests it cannot handle. This way, you will only need to manage one database of names through the WINS Manager which, in my opinion, is a much, much easier task.
I've already mentioned a few differences between WINS and DNS. They both perform the same basic functionÑtranslating a name into an IP address for client requests. WINS, however, was designed as a flat database and DNS is a hierarchical database. For most networks, this is a minor difference, because most network administrators will only need to worry about a few static names and IP address combinations. When I say flat database, I mean that the database records of a WINS server are all "equal". If I want to reference two names in a WINS database, ftp.pandy.com and www.pandy.com, I simply create two records for these names. If on the other hand, I want to add these two address to a DNS database, I add the names ftp and www to the pandy.com zone and associate the necessary IP address with them. The major benefit of DNS is that all DNS servers on the Internet work together to resolve names.
If a client attempts to resolve ftp.microsoft.com through the DNS server of their own ISP, the DNS of the ISP looks on the Internet for the Start of Authority (SOA) for the microsoft.com domain. Once found, the ISP's DNS server passes the request off to the DNS server for the microsoft.com domain. Once the DNS server of the microsoft.com domain has the request, it simple looks in its database for the server "ftp" and sends the name resolution back to the client.
The major benefit of WINS is that it works in tandem with the NT DHCP server. Remember that on a network, a DHCP server is the application responsible for assigning dynamic IP addresses to workstations when they start up. Now the problem dynamic addresses cause on a network is that a workstation may never have the same IP twice. Therefore, it's difficult to find workstations by their IP addresses. For example, one of my Win95 workstations on my network is named "pentium". When this workstation starts up, it receives a new IP address from my NT server through DHCP. If any other workstation needs to address the "pentium" workstation through TCP/IP, they'll have to know the IP address of "pentium". Because the IP of "pentium" varies, there is no way of being certain what its address is at any given time. WINS allows network workstations to address the machine name of other workstations and their IP addresses will be doled out automatically. WINS tracks all IP addresses handed out by the DHCP server and maintains a dynamic database of workstation names to dynamic IP address associations. DNS does not have this ability.
However, because the NT 4.0 DNS server has the ability to reference a WINS server when its own database fails to resolve a name, it can now also resolve dynamic IP addresses through WINS for non-Microsoft clients. This plays very heavily when dealing with Microsoft Proxy Server, if the NT server that Microsoft Proxy Server is running on also gets its address dynamically like any other workstation. WINS can be used to track the IP location of the proxy server, and workstations can continue to reference the proxy server through one name even though the IP address of the proxy server may change periodically.
By default, the WINS server is not installed when NT Server 4.0 is installed. You can install it as a network service during installation if you choose. If you have not already installed WINS, follow these steps to install it:
Figure 9.2. The lists of known NT services.
Once installed and rebooted, you will find a new application in the Administrative Tools folder called WINS Manager. The WINS Manager is the main interface for modifying the WINS database. Figure 9.3 shows the WINS Manager.
When the WINS Manager starts, it displays some stats for the local WINS services. Like nearly all NT service managers, the WINS Manager can be used to control WINS servers running on other NT servers on the network or even WINS Managers running on a machine across the Internet.
On my network, the WINS service is running on my primary NT server located at 220.200.200.1. This WINS server tracks all dynamic IP address assignments to all machines that obtain their IP address from the DHCP server (which is also running on the same NT server). To view the database of names, select Show Database from the Mappings menu,. This database (shown in Figure 9.4) will display all mappings, both recent and current.
Figure 9.4 also shows both static (manually entered IP mappings) and standard dynamically assigned IP addresses. Viewing the WINS database is a good way of seeing when an IP address is set to expire. When an IP address is received from a DHCP server, it has a lease term assigned to it. Once that lease term is up, the client must renew the IP address from the DHCP or obtain a new IP. For our need right now, there is no functionality on this dialog box that needs to be covered. Feel free to experiment with viewing the database. Its a very informative experience that will give you some insight on how TCP/IP works.
The main functionality that I deal with in the WINS Manager is the ability to create static mappings. For example, on my own network, my FTP server and my WWW server both run on my NT server, located at 220.200.200.1. The actual machine name of the server is "Controller 4.0". The Internet domain I have created for my own network is "pandy.com". Without creating a static entry for my FTP server, users on my network would have to address the FTP server as "Controller 4.0" rather than the more commonly accepted name of ftp.pandy.com. Keep in mind that all the discussion of this chapter is focused toward a network that does not have a valid, full time connection to the Internet. All the information given here is focused toward setting up WINS and DNS to support a local network only. Connecting your network to the Internet and providing full DNS support to external clients is not covered here.
I can create an entry in the WINS database for ftp.pandy.com (associated with the IP 220.200.200.1 which is the IP of the server it is running on) and thereafter all network workstations will be able to access my ftp server through the name ftp.pandy.com.
The Static Mappings option on the Mappings menu is the gateway to adding and controlling static mappings. Select this option and the figure shown in Figure 9.5 will be displayed.
As you can see, I've already created a few mappings for FTP, WWW, and PROXIES. Don't worry about this for right now. Their main purpose is for the DNS cascade to WINS. Right now, let's create an entry for ftp.pandy.com so workstations can use this name for accessing the FTP server in question.
Figure 9.6. Adding a static mapping to the WINS database.
Several different types of WINS entry types can be created; however, for our needs, only unique and multi-homed entries matter. The definition for each type of entry is as follows:
Once a static entry has been created, it is immediately available for client resolutions. The WINS server does not need to be stopped and restarted for the addition to be in effect. You can add static entries into the WINS database to reference any number of elements on your network that would not normally have an entry in the WINS database.
Multi-homed groups are very simple to create under WINS. They can be created under DNS, but this is a harder process. It's far easier to create a multi-homed group under WINS and let the DNS server reference the WINS server when resolution requests for the group are received. Creating a multi-homed group is necessary to daisy chain (also known as a round-robin group) a set of independent proxy servers together so that clients can access them as a single unit.
The real purpose of a multi-homed group is to provide support for systems which are members of two or more domains. For our purposes, we'll use it for grouping proxy servers.
When the multi-homed radio button is selected when adding a static mapping (Figure 9.6), the dialog box will change into one which looks like Figure 9.7.
To complete a multi-homed entry, do the following:
Now, any client referencing the name "proxy_servers" will receive IP resolution for any one of the members of the group. Under WINS, which member of a multi-homed group that has its IP resolved for the group name depends on several factors, such as the requester's own subnet and so on. Considering these factors helps to ensure that the proxy server closest to the requester is the one that will have its IP address resolved for the name request. However, when no one member of the group stands out as the best choice, the WINS server will choose a member of the group randomly to have its name resolved for the request.
You can test this multi-homed group by using the PING command. Try pinging the group several times from a workstation on the same subnet (so the WINS server will randomize the selection of member resolution). You should find that the IP addresses listed in the group get randomly pinged. It may take a few attempts, but you will eventually see the ping target change.
Keep in mind that for this version of Microsoft Proxy Server, separate proxy servers do not work in concert. Meaning, they do not share cache data, security settings, log files, and filter settings. Each operates independently. Setting up a group of web proxy servers in a multi-homed group under WINS helps to automatically distribute the work load between all servers when it doesn't matter which server fields a client request for Internet access. If you want to control which clients access which proxy server when there is more than one proxy server for a network, you will have to reference each proxy server independently.
Hopefully, later versions of Microsoft Proxy Server will have the ability to truly cascade proxy servers without having to go through WINS to do it.
Oh boy, setting up DNS. . . I have never claimed to be an expert on DNS however, in the same breath, I can claim to have successfully set up my own DNS server to serve out the needs of my own network. I will try to impart to you my experience in hope that you can do that same. If you are familiar with DNS, please don't be offended if my methods seem crude or poorly done. All I can say is, "It gets the job done!"
The focus of this section will be to show you how to set up your DNS server to do one thing, reference the WINS server for nearly all DNS name resolution requests. I personally prefer to use WINS as my primary name resolution database, though admittedly my needs are pretty minor in the grand scheme of Internet addressing. If you have a desire to use DNS as your primary name resolver, I suggest you run out and grab one of the multitude of books totally dedicated to covering how to set up a DNS server. This might be a little tricky though, because most of these books are customized to setting up DNS on a UNIX machine. Look around, I'm certain someone has written a DNS book on the NT 4.0 DNS Server.
The first thing to do is install the DNS server, if it is not already installed. Complete the following steps to install the DNS server:
Once the DNS server is installed, you will find a new application in the Administrative Tools folder called DNS Manager. Like the WINS Manager, the DNS Manager is the graphical interface for controlling the DNS server. Figure 9.9 shows the DNS Manager interface when first started.
When first installed, the DNS server will be pretty much non-functional. It won't have any database to serve out and it won't be linked to any IP address. The first step to take is to add a DNS server to the DNS Manager for control. This is done through the DNS menu with the Add Server option. Figure 9.10 shows the process of adding a DNS server to the DNS Manager.
Simply enter the IP address of the DNS server you wish to add. In Figure 9.10, I am adding the server at 220.200.200.1. The IP address 220.200.200.1 is the address of the network card connecting my NT machine to the rest of my network. You can also use the universal local IP address of 127.0.0.1 for the server running on the local machine. This is often the better choice because the address of the network card may change, but the local address will always be 127.0.0.1.
Once you have added a server to the DNS Manager, you will see it listed in the Server List area with several branches underneath. These branches are necessary Internet data and must be present. In a situation where a network is authentically linked to the Internet with a full time connection, these branches tell the DNS server where to locate the primary root servers of the Internet. For internal DNS needs, no data on these branches needs to be modified (thank god). If you do not see these branches, make sure the Show Automatically Created Zones option is checked in the DNS Manager Preferences (Options menu, Preferences option).
The Server Statistics part of the display is showing some DNS hit information. Your display should show all zeroes. My DNS server has been running for a while and has taken some request hits.
The next thing to do is create a Zone for your network. The Zone will be named whatever you have decided as your Internet-style domain name. Mine happens to be pandy.com and will be used in this example. If you do not have a domain name assigned to your network from the InterNic, you can select one that fits your needs.
Creating a Zone is a little confusing. Let's go over some points:
Alrighty, now that we have those points cleared up, lets create our zone. Follow these steps to create a zone:
Figure 9.11. Highlight the DNS Server on which you want to create a new zone.
Figure 9.12. Creating a new zone and indicating a new zone file
Figure 9.13. The DNS Manager with the sample zone data loaded.
Figure 9.14. Editing the SOA record.
Figure 9.15. Modifying Zone Properties.
Figure 9.16. The WINS Lookup tab of Zone Properties.
Figure 9.17. Creating the Name Server record for the zone.
Figure 9.18. Creating the localhost record.
That's it! Your DNS server should work like a charm now. If you want to use the DNS server to resolve name requests on its own rather than forwarding the requests to the WINS server, you can just create new Host records as we just did with the localhost entry. Keep in mind though, when you create a host, it is a sub-set of the zone it is create in. For example, to create a DNS record for ftp.pandy.com, you would create a host record for just "ftp" within the pandy.com zone. When a DNS resolution request for ftp.pandy.com was received by the DNS server, this "ftp" record is the one that will determine the IP resolution for the request. You cannot create any host record with a name that contains a ".".
Once you have made all of the above changes, make sure you use the Update Server Data Files from the DNS menu in order to commit your changes back to the DNS file (pandy.dns). It's also a very good idea to keep a copy of your DNS file in a safe place in case you need to restore it.
When you set a DNS server to consult a WINS server for name resolution, you have to understand how things work. When the DNS server receives a request for a resolution on ftp.pandy.com, it will pass to the WINS server only the left most portion of the name, "ftp". Because the resolution request falls within the pandy.com zone, the DNS server only wants to resolve the left portion of the request through the WINS server that is the fallback for the pandy.com zone. If you'll remember back earlier in this chapter, you will recall that my static mappings in my WINS database contained entries for "ftp" and "www". Now you should see why this is. These are the only portions of a request to ftp.pandy.com and www.pandy.com that the WINS server will receive. Since this is the case, static entries should exist which will correspond to these requests.
Remember also that we set up a group of proxy servers in a multi-homed group, called "proxy_servers". To configure clients to access the group you can set clients to address just "proxy_servers" or proxy_servers.pandy.com. If clients address "proxy_servers" the WINS server will handle the request on its own. If clients use the name proxy_servers.pandy.com, the DNS server will first receive the request and forward it on to the WINS server as just "proxy_servers". You will have to configure non-WINS aware clients (for example, Mac clients and other operating systems that do not utilize WINS) to access proxy_servers.pandy.com in order for them to correctly get name resolution on the group by the DNS server.
Setting up workstations to have access to a WINS or DNS server is a fairly simple and straightforward process. It is done through the Network Control Panel. To access this Control Panel right-click on the Network Neighborhood and select Properties. Figure 9.19 shows this dialog box.
Scroll down the components list until you find the TCP/IP protocol entry (assuming it's loaded). Highlight the TCP/IP entry for the installed network card, not the Dial In Adapter. Click the Properties button. A TCP/IP settings dialog box will appear, select the WINS Configuration tab. Figure 9.20 shows this figure.
Simply click the Enable WINS Resolution radio button and enter the IP address of the WINS server in the Primary WINS Server field. If you have more than one WINS server on your network, you can enter the location of a second one in the Secondary WINS Server field. Next, select the DNS Configuration tab. Figure 9.21 shows this tab.
Click the Enable DNS radio button to turn DNS resolution on for this workstation. The Host field and the Domain field should be filled in with the host name you are going to assign to this workstation and the Internet (style) domain name this workstation is a member of. Each workstation on a network should have a unique DNS host name. Keep in mind that the NT domain and the Internet domain are two different units. These two names together constitute the complete host name for the workstation (or server in the case of NT servers): pentium.pandy.com. Just because a host name is assigned to a workstation in this manner, don't think that it will be available for other workstations to access via commands like PING and so on. Unless the host name is listed in the WINS database, or within the pandy.com zone in the DNS server, any name requests to pentium.pandy.com will go unresolved even though pentium.pandy.com does have an IP address.
If it happens that the NetBios name (machine name set in Identification tab of the Network Control Panel) matches the host name set in the DNS configuration, then the WINS server should automatically know the IP address given to the workstation and other workstations should be able to resolve name resolution requests to the workstation (pentium.pandy.com). This discussion applies to the TCP/IP settings of NT as well, although the tab arrangement is visually different.
Once the host name and domain name have been set, you can next enter the DNS server IPs this workstation will reference for DNS requests. The TCP/IP settings can list up to three DNS servers which will be searched in sequence if necessary to resolve a DNS request. Enter the DNS IPs and then click the Add button to add it to the list of possible DNS servers.
There is a possibility that after you get a local DNS server up and running on your network, you may find dialup links made by local network workstations to the Internet are not working correctly. This is most likely because Windows is trying to use your local DNS server to handle the name resolution requests of clients attempting to access the Internet. If this is the case, you will need to add the IP address of the ISP's name server to your DNS configuration in the TCP/IP settings. Any external DNS servers should be listed before any local DNS servers so they will be tried first. When not connected to the Internet, these addresses will still be tried, though the DNS servers will not be found. Windows will then go on to attempt to access any additional DNS servers listed. This means a slight pause for name resolution when not connected to the Internet, but it will ensure that workstations can resolve Internet names when directly connected with a dialup connection.
This is a pain because Dial Up Networking entries have their own sections for indicating the name server address(s) for an ISP. You would think that when connected to the Internet, the addresses listed for the name servers used by the Dial Up connection would automatically be tried before any locally listed DNS server. This does not seem to be the case and may be a bug in Dial Up Networking. If this is the case for your workstations, simply enter the ISP's DNS address in your TCP/IP settings before your own network's DNS server IP.
Once the WINS and DNS configuration tabs have been completed, you can click OK to return to the Network Control Panel. Clicking OK again will close the Network Control Panel and you will be prompted to restart the workstation. From this point on, the workstation should be able to use both DNS and WINS to resolve names.
DNS is always checked before WINS. If the DNS and WINS servers have matching records for a network host, the DNS server's address will be the one resolved for the request.
If there are no name resolution servers on a network, a Windows 95 workstation can still perform simple name resolution on its own. This is sometimes more effort-intensive for the network administrator than just using direct IP addresses to reference the proxy server location(s).
In the c:\windows directory there can be a configuration file called simply "hosts". In fact, there is a sample file, hosts.sam, in the c:\windows directory that you can look over. All this file contains is simple name to IP associations. The format of the file is very basic. One record per line, IP address listed first (starting at the very beginning of the line, no indentation), and then the name associated with this IP. The name must be separated from the IP address by at least one space. That's all there is to it.
If Windows fails to resolve a name request from a client application by all other means available, the hosts file will be consult as a last resort. If you do not want to use a WINS of DNS server, it may be easier for you as network administrator to create a host file to copy to all network workstations. Of course, this still means some leg work to update all workstations if addresses change, but it is often easier to copy over one file than to reconfigure three or four Internet client applications per workstation.
Don't get confused by having a local name resolution server and resolving names from an outside source. Once a client has made a connection to Microsoft Proxy Server, the proxy server itself will perform name resolution for clients thereafter until the connection is broken. Obviously, if you run an isolated network, your name server is not going to know all the addresses of the outside Internet. When you create a connection to the Internet from the proxy machine, the connection method will have its own name resolution settings. For example, if you connect to the Internet through RAS, the Dial Up Networking application will allow you to indicate the name servers to be used with each ISP you call. Microsoft Proxy Server will contact the external name server(s) indicated to resolve Internet name requests for clients. Setting up a local DNS or WINS server is primarily to make it easier for clients to connect to Microsoft Proxy Server, not to enhance their ability to externally browse the network.
This was very flakey in the beta versions of Microsoft Proxy Server (known as Catapult) and didn't always work. However, the full release version of Microsoft Proxy Server is very solid at resolving names via an external name server.
When setting up proxy clients, you can choose to have them access Microsoft Proxy Server by IP or by a name. If clients access by IP, your proxy flexibility is severely limited and in a large network environment it's almost unmanageable. In order to eliminate that problem, a good combination of DNS and WINS server ability will go a long way at giving you as network administrator the tools you need. Hopefully this chapter shows you at least the basics and possibly more about how to set up both a WINS server and a DNS server to take care of all local name resolution needs.
