Name-Serving on My Mind

Accurately resolving computer names on your network is easy to accomplish. But if you don't set things up correctly and attend to it regularly, you're inviting trouble.

• By Bill Heldman
• April 01, 2003

Years ago, when I was a fresh NT administrator working on a large network I got into an issue that really scared the socks off of me. It was a mid-week workday and things were going along smoothly. I was working in the server room when one of the PC technicians came in with startling news: "Everyone's down. No one can connect to the network. Everyone just stopped working!"

At that time I knew nothing about TCP/IP. We had a combination Banyan Vines and NT network. There was an NT server running DHCP and WINS and users were happily getting their IP addresses. The setup was not configured by me so I had no knowledge about it. Neither had I studied for the TCP/IP test. I was wet behind the ears when it came to TCP/IP. I knew it was some sort of protocol and could spell TCP/IP, but that's all I knew.

Fortunately, at the time I had a support contract with a company that had several people on call for such a situation. We put in a call and got a couple of support technicians to come over right away. One of them jumped on a PC and did—I'm not kidding—three or four minutes' worth of poking around. Then he looked at me and said, "Your WINS server isn't responding." I said, "My what server?" He looked around the room, found the label of the server that he needed (someone had taken the time to label the servers with NetBIOS names and IP addresses), went over to it and logged on.

"Hmmm," he said after nosing around in the Service Manager, "Looks like the WINS service has stopped for some reason. OK to restart?" I said, "Sure!" And he successfully restarted the service. Everything came up just fine and the users were able to go about their business.

I determined right then and there that I was going to get a great TCP/IP book and study for the test. It was plain to me that I needed to know TCP/IP and name-serving in side and out.

Months later, we had a problem with another building a few miles away. A new server at that building wasn't communicating with the servers in the main building's MDF and I was stumped as to why. I put in a support call to Microsoft technical support. The rep was patient and walked me through the discovery process so he knew what our WINS environment looked like. At the time we had three WINS servers, none of which had a push/pull relationship. The Microsoft Premier Support Specialist gave me a little primer (which I thought I understood at TCP/IP test time) on how WINS handles the replication of its database as well as what the best WINS architecture scenarios look like. We walked through five or 10 minutes of setup and things took off just fine.

These two episodes have made a believer out of me in terms of how important name-serving is to a healthy network—how you can over-architect your name-server farm, and how, with the addition of DNS to the mixture (thanks to Windows 2000 servers and Win2K or Windows XP workstations) you can have a really complicated, screwed up mess on your hands if you're not paying attention.

So let's spend some time talking about the art of name-serving: what to do and what not to do. We'll talk first about WINS, then about DNS. Note that, in this column, we're going to assume you know the basics of TCP/IP and setting up both a WINS and DNS server.

WINS Is the New NetBIOS, Sorta
Windows Internet Name Service (WINS) is the software that resolves NetBIOS names to TCP/IP addresses. NetBIOS is an old Microsoft network Application Program Interface (API) and protocol that allows programmers to write code for Windows-based networks. Now, any new Microsoft code typically relies on TCP/IP and not NetBIOS. If you had a pristine new network with all Windows XP workstations and Win2K servers, you really don't need NetBIOS except for any older legacy NetBIOS applications that you had running out in the enterprise. And that's part of the rub.

Older Windows-based applications probably use NetBIOS and cannot play in a non-NetBIOS-based network—hence, the need for WINS. Because your users' client component software will probably try to hit the application utilizing its NetBIOS name and will need to resolve that name to an IP address. If the name cannot be resolved, users are out for the count. Your network—at least that application's part of the network—will grind to a halt very quickly.

It's safe to say that you will probably need to use WINS in your network until somewhere between 2005 and 2010, thanks to the proclivity of NetBIOS-based applications that are out in the world and probably running in your current network. So at least one WINS server must be up and running.

The Less Is More Principle
WINS servers use what is called a push/pull relationship. Suppose you have two WINS boxes in your network., one in campus A and one in campus B. When NetBIOS clients come up and register their NetBIOS name, they do so with the closest available WINS server. The entry then goes into the (Jet-based) WINS database for a certain period of time. If your two WINS servers don't have a push/pull relationship with one another, then server A won't know about server B's data and vice-versa. Now there might be some overlap—i.e. a client registers with server A one day and then, for some reason, manages to register with server B later on (such as a worker with a laptop carrying it from point to point), so both servers at one point or another "know" about the client. But, if the two don't share their databases with one another, NetBIOS name resolution is going to be shaky at best, especially if someone is trying to resolve a server name. Note that a WINS server can pull from, push to or both push and pull from another WINS server in the environment. In fact, you can set up a variety of push, pull and push/pull relationships with various WINS boxes in the network.

It's very important to be cognizant of the fact that in the WINS world less is definitely more. You don't want very many WINS servers in your enterprise, no matter how large the enterprise is. So it's critical that you set up a design whereby you have very few WINS servers, you architect the the push/pull relationships with the servers in your enterprise and you have a designated someone who routinely checks things out to make sure that everything's running OK.

WINS code is some of the most tested code in Microsoft-land and I can tell you that if you've correctly configured your WINS layout, generally speaking the failure isn't with WINS—you're having problems with something else. That being said, most neophyte administrators are quick to blame WINS for all of their troubles. Not usually so! Let's discuss some basic rules of play:

• Designate one master WINS server
• Set up your push/pull operations so that your other WINS servers push to and pull from that central box
• Keep the WINS servers to a minimum (I've heard some Microsoft PSS folks recommend no more than three for large enterprises—generally I'd recommend a WINS box for each geographically disparate site
• Never under any circumstances, key a static entry into the WINS database unless it's for non-NetBIOS hosts that need NetBIOS client resolution (such as UNIX or Linux hosts). Do not key in static entries for Windows-based computers!

Do not let everyone manage your WINS servers and database. Keep management of the WINS environment down to just a couple of admins. If everyone can access the WINS management interface, before you know it your WINS environment is going to be corrupted. Admins can remotely manage WINS so there's no need for remote admins to feel that they need to control the WINS database.

Static Entries—How's That?
What do I mean by "static entries?" Suppose that you have a computer that NetBIOS-based users need to access. Microsoft gives you the ability to manually key an entry into the WINS database that will allow these users to connect to the computer. You could do this with a big UNIX server that users need to connect to in order to run some ERP software for example.

Unfortunately, junior admins who are trying to troubleshoot TCP/IP name-serving problems often resort to simply keying a static entry in for a Windows-based host. This kind of thing treats the symptom, not the problem. The problem is that you've got a host that is failing to register its name with the WINS server. The trick is to go to the host, perform some elementary TCP/IP troubleshooting, examine the TCP/IP configuration, and then work with the NBTSTAT command to get the machine's NetBIOS name registered. (Run NBTSTAT /? for help on the command syntax.) By simply keying in a static entry, you run the risk of fat-fingering the entry and knocking the machine out of client reach. Also you might forget that the entry is in there. If the TCP/IP address or the machine's name changes and you keep the old address, then you have a very difficult to diagnose problem on your hands.

You should establish a firm, unbreakable rule that static entries are reserved solely for non-Windows-based hosts, period. If you catch another admin keying a static entry into the database in an effort to troubleshoot WINS issues, you have my permission to lecture him or her for at least an hour!

Rogue WINS Servers
Lots of people are studying to take the Microsoft certification tests. What would happen if Joe over in Marketing was messing around one day in preparation for the test and set up a WINS server on the network? Users within logical proximity of that WINS server would likely register with it and then attempt to resolve IP addresses from it. But the server is dumb as a stick when it comes to your production boxes because it's not within logical reach of your production boxes and it doesn't have a push/pull relationship with the other WINS servers on your network (nor do you want it to have one). Users are frustrated because they get cute little error messages telling them a host isn't available—even though you've validated that it's up and running. You run around for hours tearing your hair out trying to find out what the problem might be.

Question: How long would you have to troubleshoot something like this in order to find the problem? Answer: A long time! I've heard stories of admins actually rebuilding servers in an attempt to try to solve this problem. All the while, Joe's completely unaware that he's responsible for the network not being operational.

This type of WINS installation is called a rogue server. Windows 2000 and beyond WINS servers allow you to block rogue WINS servers from registering your W2K and Windows XP clients. It's a good idea and one you should implement.

Hosts Getting Wrong WINS Info from DHCP Config Info
When you set up your DHCP scopes, you generally provide what is called configuration information that is passed to the client at client lease renewal-time. If you've incorrectly entered the WINS server address (or changed its address), or if you've built a new WINS server with a new name and address but failed to update the DHCP scopes, clients will stop being able to resolve NetBIOS names.

To solve a problem like this, your PC Technicians will most likely run the IPCONFIG command and note that the information's incorrect, but they won't be able to fix the problem. Instead, they'll force the client's TCP/IP configuration by statically entering the correct WINS addresses in order to get the client going again. This might be fine, except that they generally don't go back later and set the client back to automatically receive its WINS information through DHCP once the problem's fixed. So now you have a self-perpetuating problem. The next time you make a WINS server change, the PC Techs are right back at it again.

How do you fix this? Proactively, my friend, proactively. When you know you're going to move or change a WINS box, make sure that you take the time to get your DHCP clients refreshed with the new configuration information as you roll out the new server. (This can take awhile. Making changes to DHCP scopes can be challenging by itself.)

If All Else Fails
There are lots of helpful docs on the Web that can teach you how to repair and rebuild your WINS database using the Jet utilities. You would do this kind of thing if you notice corrupt nonsensical characters in the WINS registrations. For example, a computer named DESERET probably shouldn't show up in the WINS database as DE$3RET. There's something wrong and you need to repair the WINS database.

I've seen experienced admins totally blow out the WINS database and start all over again—going from server to server and running the NBTSTAT -RR command to reregister the boxes with WINS. Personally, I think that this should be a last resort. Generally speaking, if you examine the WINS databases and all looks to be in order, you have bigger fish to fry. Note that you can examine all of your WINS servers' databases from a single management console (providing that you have connectivity with the various servers—if you don't, then you've got your answer). I'll probably get a lot of email disagreeing with me on this, but WINS code works and works well. You can trust what WINS is telling you.

Domain Name Server
If you have Windows XP or Windows 2000 hosts, they natively use DNS, without needing NetBIOS to resolve names—provided, of course, that you don't have any applications that require NetBIOS name resolution. (Note that Windows XP and 2000 workstations can fully utilize WINS with no issues, should you require it.)

DNS resolves a Fully Qualified Domain Name (FQDN) to an IP addresse. If you have an address, for example, of server.mydomain.com, the DNS servers should have an entry in them that will resolve the name to an IP address. If we didn't have DNS, we'd have to memorize lots of IP addresses in order to go anywhere on the Internet!

DNS also maintains a reverse lookup table (called in-address.arpa) that can resolve an IP address to an FQDN. You can use the NSLOOKUP command to retrieve the FQDN for a given computer if you know its IP address. (Note that if you use a PING command with Windows-based systems, you'll not only get the IP address back, but also the FQDN or NetBIOS name of the host, depending upon the primary type of name-resolver the host is utilizing. Using PING to query a host and then observing whether you get a NetBIOS name or FQDN back can be a handy troubleshooting technique when working on name-resolution problems.)

Secondary Zones
DNS uses zones, similar to the Windows Explorer file-folder structure, to logically group hosts. There are Active-Directory-integrated primary and secondary zones associated with a DNS server. An AD-integrated DNS system stores its DNS information in the Active Directory. A primary zone stores its info in a text file with the extension of DNS. A secondary zone receives its DNS information from a primary DNS server. Typically, secondary servers act as backups for the primary servers across LAN links (as in a campus layout) or WAN links. They're not necessarily needed for AD-integrated implementations. You can get away with having two duplicate primaries that act as backups to one another in such a situation.

• Secondary zones can give you trouble for a variety reasons:
• Someone deletes the secondary server's IP address from the Notify list in the primary server (non-AD-integrated only)
• WAN or LAN links go down and the secondary server is unable to get an updated listed from the primary (by default the secondary is refreshed every 15 minutes)
• Secondary server's NS record deleted from the primary for some reason

Root Hints and the Cache.dns File
The "dot" domain in a DNS server implies that the server thinks it is a top-level DNS server. Thus, at least as far as the root DNS server is concerned, there is no upper authority from which it can request information. But in DNS servers that interface with the Internet, there is another level of name-resolution authority beyond them and that is the DNS servers that are authoritative for the Internet.

For this reason, every DNS server contains what is called a "root hints" file. This file contains the server names for Internet-authoritative DNS servers. DNS servers with root hints files can forward their information (and potentially name information you don't want out on the Internet) to external DNS servers for resolution.

When you run DCPromo.exe you are given the option to create a DNS server and configure forward lookups for that server. When you run this portion of the wizard it queries the DNS entries that have been made for this computer and then, using this DNS info, searches for other root servers in the forest. If the wizard finds no DNS entries, it then uses the root hints file (Cache.dns) and queries the external (Internet) servers. If none of the external servers respond, the wizard tags this computer as a root-level DNS server and adds the dot domain, indicating that it is now a top-level server.

There are two issues with this scenario:

• Chances are you don't want every DNS server accessing the Internet. What you really want is a forwarding DNS server that acts as the gateway to the Internet for your network. You can configure all of your internal DNS servers to forward any requests they cannot satisfy to the forwarder. You use the DNS Manager interface to configure forwarders. The great part about setting up a DNS forwarder server is that it develops a robust cache and over time can begin to quickly answer resolution requests.
• If a DNS server thinks it is a top-level server it will never forward Internet name resolution requests out the door. It has no root hints file for this purpose! You want a setup in which your forwarder server utilizes root hints to pass name resolution requests up the line.

There are a number of documents on the Microsoft Web site that talk about setting up a good-quality DNS architecture—one that reliably resolves names, whether Internet or local, does not compromise internal network security and that quickly meets the needs of users.

Read-only DNS Servers in the DMZ
DNS servers that will reside on your corporate DMZ and will be used for name-resolution by hosts hitting your Web sites need to have a couple of special settings:

• These need to be servers that contain only entries for the DMZ—not internal servers
• The data must be read-only and not be able to be modified
• If there is a need for your DMZ DNS boxes to resolve internal names, consider a VPN connection between the external boxes and your internal DNS servers (perhaps utilizing an ISA Server VPN)

It is advisable to pay careful attention to DNS servers that sit out on the Internet and are thus privy to hacking. The last thing you want is for a hacker to obtain internal server information by simply gaining access to your external DNS servers.

Say My Name
In this article we've discussed some of the reasons for the importance of paying a lot of attention to name-serving and have given you ideas about where things can go wrong. This is in no way a full and complete treatise on the subject—name-serving is a vast topic (especially in the W2K world where, for example, W2K DNS servers can get some of their DNS info from WINS) and requires that you do quite a bit of research and investigation in order to make yourself an expert in this area. A well-understood name-serving environment that you judiciously manage is going to alleviate a lot of problems in your network.