Windows 2003 Gems

Windows Server 2003 will soon debut, and IT shops will need to make the decision whether to upgrade. Windows 2003 presents perhaps the toughest "Should I bother upgrading?" decision since the release of Windows NT 3.51. At first glance, Windows 2003—like NT 3.51—seems to offer few new features, and none of the individual features it does offer are of the type that grab you by the throat and demand that you have them. But when you consider these features as a whole, Windows 2003—also like NT 3.51—is appealing even to the most curmudgeonly of current Windows 2000 Server users.

Consider Windows 2003's stub zones and conditional forwarding for DNS servers. If you've ever designed an Active Directory (AD) infrastructure, you understand the importance of implementing a good, solid DNS infrastructure before thinking about AD. That DNS infrastructure will need to store a bunch of information about AD—information that you don't necessarily want the world to see. Rather than build AD on a publicly visible DNS server, most of us end up creating a split-brain DNS infrastructure that's largely disconnected from the outside world.

In a split-brain environment, you build the DNS server for your AD domain. If you're creating an AD infrastructure called bigfirm.biz, you'd first set up a DNS server to act as a primary DNS server for a DNS domain with the same name: bigfirm.biz. That DNS server will hold the information that computers in your network will need to find your AD's domain controllers (DCs) and Global Catalog (GC) servers—the information you don't want the world to see. Now for the sneaky part: Typically, if you're creating a DNS server for bigfirm.biz, you'd register the domain name bigfirm.biz with a DNS registrar such as register.com. But you don’t want to register the domain name in this situation because you don't want people to easily find your AD-supporting DNS server. However, if the rest of the world can't find your bigfirm.biz DNS server, how do the people inside your network find it?

If you have one DNS server and one DNS domain, the solution is easy. Build bigfirm.biz on that DNS server, then tell every computer on the network to go to that DNS server if it wants DNS names resolved. Because the DNS server contains information for your internal bigfirm.biz domain, the DNS server never needs to search the Internet for information about bigfirm.biz. All is well.

But running just one DNS server in a domain is a bad idea. If you have a lot of machines hammering on one DNS server for name resolution, you'll have a slow network. You'll soon want more DNS servers. After you have those DNS servers running, you'll spread the load among them: Some computers will look to DNS Server 1 for name resolution, some to DNS Server 2, and so on.

If a machine's preferred DNS server isn't one that holds the internal-only copy of the bigfirm.biz domain, what happens when that machine wants to log on and asks for the names of the DCs for bigfirm.biz? Unless the DNS server that you query contains a copy of the domain information—the “zone”—for the bigfirm.biz DNS domain, that DNS server will naturally search the Internet for bigfirm.biz information, and the DNS server it ends up with won't be able to help much in the search for a DC. The solution is to ensure that every DNS server inside your intranet is a secondary DNS server for bigfirm.biz.

That solution works for networks that use AD and Windows 2003– or Win2K–based DNS servers. But the solution isn't perfect. When the bigfirm.biz DNS information changes on the primary DNS server, the primary DNS server must replicate all of that information to all the secondary DNS servers—which could mean a lot of replication. Suppose you have 30 DNS servers. You want to spread out the job of offering DNS domain information for bigfirm.biz, but you decide that you don't need to spread it out to all 30 servers. Thinking five servers will do the job without creating too undue a replication burden, you make five of the DNS servers secondary servers for the bigfirm.biz zone.

But if you do that, you have 24 DNS servers that don't know where to go to find your internal bigfirm.biz zone. You solve this predicament by creating a bigfirm.biz stub zone on each of the 24 servers. A stub zone is a shortened version of the bigfirm.biz zone. Unlike a secondary DNS zone, a stub zone doesn't include all the information about the bigfirm.biz domain. Instead, it simply directs DNS servers looking for bigfirm.biz’s DNS servers to one of those bigfirm.biz DNS servers. (You can use stub zones only on Windows 2003–based DNS servers—not on Win2K-based DNS servers.)

If you create more than one split-brain domain within a network, you run into a similar problem. Suppose you work with a partner firm that also has a split-brain DNS setup. Your AD infrastructure is named bigfirm.biz, and the partner firm's AD infrastructure is named coolstuff.com. The partner firm has an internal DNS server that contains the internal-only version of the coolstuff.com domain—just as you have a DNS server that contains the internal-only version of bigfirm.biz. Anyone in your network can find information about (and thus potentially log on to) your bigfirm.biz AD infrastructure, and members of the partner firm's network can do the same in the coolstuff.com AD infrastructure. However, suppose you decide to trust each other's domains. You would need to be able to find the coolstuff.com DCs, which you would do by finding the firm's internal-only DNS, and the partner firm would need to be able to find the bigfirm.biz DCs. Even considering a trust between two domains is impossible if their internal DNS servers can’t communicate with each other. How can you make those DNS servers see each other?

Stub zones are one answer. But you would need to permit coolstuff.com's DNS servers to continually replicate information from your DNS servers—and you might not trust them that much. Windows 2003 DNS offers another answer: conditional forwarding. Under conditional forwarding, if a machine queries your DNS servers about the coolstuff.com domain, your DNS servers know to go directly to those coolstuff.com DNS servers to get the answer to that machine’s query. The difference between stub zones and conditional forwarding is subtle but important: Stub zone servers must be able to transfer zones from your DNS servers, so if you put bigfirm.biz stub zones onto the coolstuff.com domain's DNS servers, you would compromise your DNS security to a certain degree. Conditional forwarding would tell the coolstuff.com DNS servers to perform only traditional queries of your DNS servers—a little less revealing. As you might guess, conditional forwarding for DNS servers doesn't work on Win2K. . . .

You must log on before posting a comment.

If you don't have a username & password, please register now.