DNS and WINS help you resolve names so you can connect to remote computers across the LAN and across the Internet. WINS resolves computer (NetBIOS) names such as \\surtur, and DNS resolves host names such as surtur.paradigms.com. To help clarify some confusion surrounding the different types of name resolution, this sidebar describes the steps a network takes to resolve computer and host names.
Table A shows the properties for three computers in a TCP/IP network. (Note that this network contains just one WINS server and is not the same network described in the main article.) Two NT computers (\\patmos and \\samos) are in one domain, and a Windows 95 computer (\\tadpole) logs in to that domain. In this sample network, a WINS server runs on \\patmos, and \\samos and \\tadpole point to that server to resolve NetBIOS names. DNS runs on \\patmos and \\samos, and \\tadpole points to \\samos to resolve host names. Listing A shows the contents of the DNS configuration files on \\patmos, and Listing B shows the contents of the DNS configuration files on \\samos. Let's investigate both types of name resolution.
NetBIOS Name Resolution
Clients resolve computer names such as \\patmos and \\tadpole with NetBIOS name resolution. Suppose a user on the NT server, \\samos, issues the command netusex:\\patmos\data
to display information about that computer connection. If you configure \\samos to use WINS, host files, DNS, and lmhosts files, \\samos follows a series of steps to resolve a computer name.
1. The \\samos server checks a local NetBIOS name cache for the \\patmos computer name. If \\samos finds the name in the cache, it uses that cached name to resolve the NetBIOS name.
2. If \\samos doesn't find a cached name, it tries three times to contact the \\patmos WINS server. A WINS resolver on \\samos uses a hard-coded IP address (126.96.36.199), rather than a NetBIOS or host name, in the TCP/IP configuration so that the resolver can access the WINS server without needing to know that the resolver is accessing \\patmos. The resolver's success in accessing the WINS server depends on whether WINS is running on \\patmos and whether the resolver finds a mapping (a correlation between the physical IP address and computer name) in the WINS database for \\patmos. If the resolver finds a \\patmos mapping, it uses that mapping.
3. If WINS is not running and the WINS resolution fails, \\samos tries three times to resolve the name by sending out name query requests in the form of broadcasts. Each computer on the network receives the broadcast and checks its name cache to see whether this computer owns the nameif so, the computer sends a name query response, using Address Resolution Protocol (ARP) to obtain the source host's hardware address. This broadcast will succeed on a local network such as our sample network but will fail in a routed environment because most routers aren't configured to forward broadcasts.
4. If we add a router and the broadcasts fail, \\samos checks its local lmhosts file for a \\patmos entry. If \\samos finds a \\patmos entry, it uses that entry. Our sample network has no entry in \\samos's lmhosts file for \\patmos.
5. If the lmhosts file lookup fails, \\samos tries a hosts file lookup. Again, our sample network has no entry for \\patmos.
6. Finally, \\samos sends a request to its configured DNS, which is local in this case. The resolution will work if the DNS completes a zone transfer from the primary Domain Name Server for sakellariadis.com.
If we enter the same net use command from \\tadpole, we see a similar series of events. The \\tadpole system will check its local files or send requests to the WINS server at 188.8.131.52 or to DNS on \\samos.
|LISTING A: Configuration File Contents on \\Patmos|
primary sakellariadis.com sakellariadis.dom
secondary aegean.com 184.108.40.206 aegean.dom
patmos.sakellariadis.com. IN A 220.127.116.11
samos.sakellariadis.com. IN A 18.104.22.168
|LISTING B: Configuration File Contents on \\Samos|
primary aegean.com aegean.dom
secondary sakellariadis.com 22.214.171.124 sakellariadis.dom
tadpole.aegean.com. IN A 126.96.36.199
Host Name Resolution
Clients resolve host names such as patmos.sakellariadis.com with host name resolution. Suppose a user on the NT server \\samos issues the command ping patmos.sakellariadis. com to verify the connection to that remote host. If you configure the \\samos server to use all possible methods of name resolution, the system follows a series of steps to resolve the host name.
1. The \\samos server checks whether the host name matches the local host name. In the sample network, it doesn't.
2. If \\samos doesn't find a match, it parses the hosts file. If \\samos finds an entry in the parsed hosts file, it uses that entry. In our sample network, no entry for \\patmos is in the hosts file, so this search fails.
3. The \\samos server sends a request to the configured DNS, which is local in this case. The resolution will succeed if DNS completes a zone transfer from the primary Domain Name Server for sakellariadis.com.
4. If DNS doesn't complete the zone transfer, \\samos checks its local NetBIOS name cache for the host name.
5. If \\samos doesn't find the cached name, it tries once to contact the WINS server at 188.8.131.52.
6. If WINS resolution fails, \\samos broadcasts three times to try to find the remote host, as in Step 3 of the NetBIOS name resolution procedure.
7. If you use a router and the broadcasts fail, \\samos checks its local lmhosts file for a \\patmos entry. If an entry for \\patmos is in the lmhosts file, \\samos uses that entry. Our sample network has no entry in \\samos's lmhosts file for \\patmos.
If you follow these steps for a network with the IP addresses shown in Table A, the attempt to ping patmos.sakellariadis.com by name will work because Step 3 will succeed. If the DNS zone transfer hasn't happened, however, the ping succeeds at Step 6.
|TABLE A: Sample TCP/IP Network Properties|
|Operating System||NT 4.0||Windows 95||NT 4.0|
|DNS Server - 1ry||sakellariadis.com||N/A||aegean.com|
|DNS Server - 2ry||aegean.com||N/A||sakellariadis.com|