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
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 didI'm not kiddingthree 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 networkhow 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 networkhence, 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 networkat least that application's part of the networkwill
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 overlapi.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 WINSyou'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 enterprisesgenerally
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 EntriesHow'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
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 availableeven 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 againgoing 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 serversif 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 namesprovided, 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.)
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 architectureone 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 DMZnot
- 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 subjectname-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.