In some ways, Windows 2000 DNS seems to be merely a replacement for WINS under Windows NT 3.51 and later. Because NT 4.0 doesn't depend much on DNS, most of us don't think much about our DNS infrastructure. In contrast, WINS under NT requires quite a bit of thought, in particular about how many WINS servers you need. Having many WINS servers makes for speedy name resolution, which is good. But having many WINS servers also leads to replication and database-corruption problems, which is decidedly bad. Consequently, WINS architecture is something of a balancing act.
In comparison, DNS is generally a more trouble-free naming service than WINS. In this column, I explain why.
The Workings of WINS
WINS and DNS are both name-resolution systems, which means that they keep track of the name and IP address of every system on your network. That tracking is a great convenience: Because WINS and DNS know both the name and IP address of all your computers, you can assign your computers relatively easy-to-recall names, such as \\mypc or mypc.acme.com, and let WINS or DNS remember the computers' more cryptic IP addresses. Thus, you can use the friendlier names for all your network usage and administration tasks and rarely need to deal directly with IP addresses. For example, when you type
net view \\mypc
at a command line, your system automatically knows to ask a WINS server to convert the name \\mypc to the computer's IP address, or more technically, to resolve the name \\mypc.
Every NT 4.0 or NT 3.51 system running TCP/IP (or for that matter, any Windows 9x or Windows for Workgroups—WFW—3.11 system) needs to know the IP address of a WINS server that the system can count on to resolve names. That WINS server, which is called the system's primary WINS server, performs two functions: system registration and name resolution. In my opinion, the fact that WINS uses the same server for both system registration and name resolution is a weakness of NT. Let me explain why.
WINS can't resolve names to IP addresses unless it knows the names and addresses of the systems on your network. Where does it get that information? Every system that relies on WINS for name resolution must contribute to WINS's database of names and addresses. In other words, each WINS-using client system must register its information with a WINS server: "Hi, WINS. This is \\mypc, and I'm at address 10.4.15.11. Please tell anyone who is looking for me to go to that address."
But systems don't register just once. WINS servers remember systems' address information for only a few days, depending on how the administrator set up the WINS server. So systems reregister with WINS regularly—every time they boot and whenever they renew their DHCP leases, for example. Consequently, a WINS server is usually busy in the morning because it needs to accept a lot of registrations from machines that employees boot in preparation for the workday.
You'd think that you could lighten the registration load by increasing the number of WINS servers on your network and assigning fewer workstations to each one. However, that's not a good idea. All those WINS servers need to share the names and addresses that they learn, combine them, boil them down to one unified database, then distribute that database to all WINS servers so that each WINS server can resolve every name in the network. This boiling-down and distribution process is called replication. If you install more than a dozen or so WINS servers in your enterprise, the process can go awry, leaving a corrupted and useless database. As a result, Microsoft has always said that you shouldn't have more than 15 WINS servers in your entire company, no matter how large or geographically distributed the company is.
But remember that WINS servers serve two functions. In addition to registering systems, WINS servers resolve names. Clearly, you'd like your network to respond quickly to name queries. One way to achieve the desired response time might be to have a large number of WINS servers, each with a copy of the WINS database. Each WINS server might serve only a hundred or so workstations and therefore could respond speedily to name-resolution queries. Unfortunately, that approach doesn't work because it also gives you many registration-taking WINS servers and thus opens the door to potentially unacceptable replication difficulties.
The Differences in DDNS
Let's imagine a better approach. What if you had a small set of WINS servers that only took registrations and a much larger set of WINS servers that only responded to queries? The few registration-taking WINS servers could keep a nice, clean database and would see to it that the query-only WINS servers would always have the most up-to-date database. You'd have to change things around a bit on the client side because you'd have to tell workstations the names of two WINS servers. For example, you'd tell \\mypc, "When you need to register or reregister, go to WINS server A, and when you need to resolve a name, go to WINS server B." If you think that system seems better, then you're going to like dynamic DNS (DDNS) under Win2K. With DDNS, your workstation registers its name and IP address with a particular DNS server but might turn to a different DNS server to resolve names.
In the standard DDNS world, only one DNS server accepts all the registrations for your entire domain. (If you're running Win2K DNS servers, you can change that, but let's restrict this discussion to standard DDNS implementations.) That DNS server, which is called the primary DNS server for its domain, stores all the registered names for the entire domain in a file called a zone file. (Note to the DNS techies reading this column: I know that I'm blurring the line between zone and domain, but because of space limitations, we'll take that up another day. For now, don't worry about the difference.)
To provide DNS servers that can resolve names for your domain, what do you need? The easiest answer is that you need to set up some DNS servers. They don't need to be running DNS server software that supports DDNS. Nor do they need to possess a local copy of your domain's zone file, because unlike WINS servers, DNS servers can resolve names for domains they've never heard of. DNS servers simply search the hierarchy of DNS names and servers to find a server that can resolve the name query, then obtain that server's assistance to resolve the name. For good measure, DNS servers remember (i.e., cache) each name query request. As a result, if you ask a DNS server to resolve the same name in the near future, the DNS server has the information it needs to immediately resolve the name. DNS servers that only resolve name queries and aren't responsible for any domains are called caching-only servers.
Under WINS, your workstation needs to reregister with the WINS server that resolves names. Under Win2K DDNS, the DNS server specified as your workstation's preferred DNS server only resolves names. When your workstation needs to reregister with the primary DNS server on your domain, your workstation tells its preferred DNS server, "I'm part of the acme.com domain. Please tell me who is the primary DNS server for acme.com." In more technical terms, your workstation asks its local caching-only DNS server to retrieve the Start Of Authority (SOA) record for the acme.com domain. The SOA record contains several pieces of information about the acme.com domain, including the DNS name (not the IP address) of acme.com's primary DNS server. Armed with that information, your workstation knows who to contact to reregister.
So DNS seems to afford us greater flexibility in offering as many name-resolution servers as we could want. But what about the registration side? It seems that every system in the enterprise will have to reregister every day on the domain's primary DNS server. Won't that requirement cause a problem?
Potentially, yes. But that problem might not be severe. For one thing, reregistration might not be necessary as long as your workstation's IP address doesn't change. Unlike WINS records, old DDNS records don't expire and disappear by default (although you can change that behavior if you want to). So if the primary DDNS server is too busy to reregister your workstation, you probably won't notice because your workstation already has a record in DNS. But for overloaded primary DDNS servers, DDNS offers an option called Active Directory integrated zones. This option lets you spread the registration-taking responsibility among all the Active Directory (AD) domain controllers (DCs), which all act as DDNS servers.
I'll reserve a discussion of AD integrated zones for another column. But you can see that all in all, DDNS seems to be a major improvement over WINS. For more information about the workings of WINS and DNS, see "Related Articles in Previous Issues."
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. ZUBAIR AHMAD "Dynamic DNS Updates in Windows 2000," September 1999 Web Exclusive, InstantDoc ID 7187 ALISTAIR G. LOWE-NORRIS "Tombstones Mark the Coming of the End for WINS," March 1999, InstantDoc ID 4881 MARK MINASI "A DNS Primer," January 2000, InstantDoc ID 7733 Inside Out, "A Root of Your Own," November 1999, InstantDoc ID 7306 Inside Out, "WINS Proxy Agents," October 1997, InstantDoc ID 120 Inside Out, "Advanced WINS Features," September 1997, InstantDoc ID 111 MICHAEL D. REILLY Getting Started with NT, "Domain Name Resolution with DNS," June 1999, InstantDoc ID 5408 Getting Started with NT, "Implementing WINS," May 1999, InstantDoc ID 5212 |
