Folks with a 255.255.255 subnet mask typically have two DHCP servers for a reasonably large (less than 300 machines) switched network; this way, they can split the scope into around 127 addresses apiece. Remember, a DHCP scope is the range of addresses served by the server. In this case, let’s say the subnet address is 167.195.191.0. One server’s scope might be 167.195.191.10–167.195.191.127; the other server’s scope might be 167.195.191.128–167.195.191.254.

There’s a lot to be said for keeping a large amount of eggs in two baskets. (The actual quantity of numbers available for each server’s scope will actually be less than 254 divided by 2, because items such as routers and servers have nondynamic IP addresses and use some of the addresses.)

TCP/IP Name Resolution

The thing that always confused me when I started networking with Windows and TCP/IP was this: Why are there two types of name resolution? After the discussion in Hour 1, you’re probably comfortable with the fact that any network name typically needs to be resolved to a network address—that is, when you point your browser to www.jotto.com, the browser resolves this name-oriented address via DNS (Domain Name Service) to the network address 205.134.224.21.

Therefore, like me, you’re probably wondering, why not just use DNS the way other operating systems that use TCP/IP do? It always seemed crazy that Microsoft created a new type of name service just for Windows. Let’s take a look at how WINS fits into the Windows TCP/IP picture, and then we’ll glance at how Microsoft integrated DNS as well.

Windows WINS!

Windows Internet Naming Service, or WINS, was invented to make networking Windows machines easy, even over a wide area. Because you know that NetBEUI is not a routable protocol, it makes sense that a different protocol needed to be used to connect Windows-networked machines. TCP/IP was fine and could carry NetBIOS, but some of the ways that name resolution used to happen in NetBEUI needed to be redone for TCP/IP. In particular, when your domain can be spread over several subnets, using broadcasts for name resolution no longer works—broadcasts typically only affect your local subnet.

WINS is the answer to how machines can resolve names without broadcasting. The WINS server keeps track of Windows workgroups, domains, and machine names on a TCP/IP network. Instead of a machine broadcasting to the network, that machine can instead contact the WINS server and get the necessary information. This is called a point-to-point name resolution; machines that resolve names this way are called p-nodes. As clients talk to the WINS server, it notes what IP addresses they have and what workgroup they belong to and then updates its database.

The WINS server program, like DHCP, runs only on Windows NT. There’s no WINS server for workgroups. Its function is to keep a database of domains, workgroups, and PC names, and to distribute these names and their associated IP numbers to anybody who asks for them.

You have all sorts of options for replicating your database to another WINS server, adding static mappings, and so on, but it’s not worth going into in detail here. Check out the NT Resource Kit (available online) if you’re interested. The bottom line with WINS is this:

1.  You start WINS running.

2.  As PCs connect to it, it registers the computer names in its database.

3.  WINS distributes this information as required by other workstations and servers.

You can drive yourself nuts with WINS very easily; keep it simple and you’ll be okay.

---

Your NT server that runs the WINS server should use itself as its own WINS server. Sounds crazy, huh?

---

---

It’s absolutely crucial that you use the latest NT service packs with WINS. Some extremely evil problems have been fixed.

Service packs are accumulated fixes that Microsoft makes available via its Web site or on CD-ROMs. Applying one service pack fixes a whole host of potential problems. A service pack differs from a hot fix in that Microsoft has deemed service packs safe for all users, whereas hot fixes are only applicable to users who are having a particular problem.

---

Using DNS

DNS can be used as a naming service as well, but this will make your initial connections somewhat slower. DNS does not have facilities to differentiate between workgroups, domains, and computer names. Each DNS entry specifies a hostname only.

Windows 95 automatically uses DNS resolution if other things fail; NT needs this explicitly set up in the network Control Panel under the TCP/IP protocol. Make sure the Use DNS for Name Resolution check box is checked if you wish to use DNS.

Most of the time, you’ll not want to use DNS; WINS comes with NT and is dynamic and relatively easy to use. DNS is somewhat trickier to set up and doesn’t offer as much to the Windows networking world.

The only time you’ll want to set up the Microsoft DNS server is if you’re acting as a Web server. Because you’re then participating in the Internet’s network—which is not a Microsoft file and print network—DNS is the only option. Using DNS for internal Windows network name resolution doesn’t make sense most of the time.

---

Does all of this seem like a mess? You’re not going crazy: It is a mess. There are too many pieces and parts to keep track of with TCP/IP and Windows. Microsoft fans are really, really, hoping that future releases will comb some of the tangles out, and no doubt NT 5.0 probably will, but we’ll have to wait awhile to find out. In the meantime, take it slowly; it’s not too bad once you get the hang of it. See Figure 11.2 for a sample Windows network that uses TCP/IP. In it, you’ll see that PCs are configured upon bootup or lease expiration from the DHCP server on their local segment, which configures them with IP addresses and with the configuration information they need to resolve names from their local WINS server. It’s not too awful. You have just a couple of things to set up.

---

Figure 11.2  A sample Windows TCP/IP network.