Uproot DNS and Disable NetBT

Get an answer to a common DNS question and learn how to use DHCP to disable NetBT

This month, I have two short topics for you. The first is an answer to a question readers frequently ask me about DNS. The second keeps a promise that I made in a past column to show you how to use DHCP to disable NetBIOS over TCP/IP (NetBT) on your Windows 2000 machines.

Uprooting DNS
Suppose you've set up a Win2K-based DNS server on your network. To configure it, you right-click within the Microsoft Management Console (MMC) DNS snap-in window, then choose Properties. Then, some strange things happen. You can't access the Forwarders tab because it's grayed out, so you can't tell the DNS server to use a forwarder. The Root Hints tab is also grayed out, so you can't change the list of root servers that your DNS server knows about. What's going on?

For some reason, Win2K configured your DNS server as a private root server. Recall that DNS is a hierarchy of names, as in the Fully Qualified Domain Name (FQDN) www.minasi.com.—and yes, that period at the end of the name is deliberate: No DNS name is complete without a period (.) at its end. This name reflects that a machine named www is in a domain named minasi, which is a child domain of the domain named com, which itself is a child domain of the topmost domain of all—the root domain. But we don't spell the root's name out; we represent it with a period. (For information about roots, see "A Root of Your Own," November 1999, InstantDoc ID 7306.) An actual DNS server—13 of them, in fact—contains the DNS records for the root domain. And that domain is queried quite a bit—you typically can't find other domains without first finding the root.

Win2K's DNS server knows that. The first time that you start up a Win2K-based DNS server, it appears to look for the root domain. If the server doesn't find a root domain, it seems—I say "seems" because this behavior appears to be inconsistent—to respond by saying "if I can't find a root, then I must be the only DNS server in the universe" and creating a root domain on itself, in effect disconnecting from the public DNS hierarchy. The server solipsistically decides that it's the authority and that trying to find another DNS server is pointless. Until you cure the server of its delusion, it won't be much good.

Well, let me rephrase that a bit: At times, you might like to have a DNS server unconnected to the public DNS hierarchy. A very secure network, completely disconnected from the Internet, wouldn't need to be able to search the public DNS hierarchy. But in most cases, this situation isn't what you want.

Telling a DNS server that it isn't the root shouldn't be difficult, but it can be frustrating if you don't know how. Here are three ways to introduce your server to the rest of the world. I explain all three so that I can also offer some insight into how to do a bit of under-the-hood work on DNS.

All the methods share the same basic approach: They delete the root domain from your DNS server. The command-line method uses a command called dnscmd.exe from the Win2K Server Tools add-on. You'll need to install the command; you'll find it in the supporttools folder on the Win2K Server CD- ROM. Then, you can delete the root from your DNS server by typing

dnscmd /zonedelete .

The period at the end of the command is the name of the zone to delete. You must use Dnscmd's /dsdel option if the zone you're deleting is an Active Directory (AD)—integrated zone (although I'm not sure how you'd end up with an AD-integrated root domain). In the command, case doesn't seem to matter.

After you execute the command, I recommend restarting the DNS service. Then, open the DNS snap-in, and you'll see that the Forwarders and Root Hints tabs on the server's Properties page are no longer grayed out.

You can also deroot a DNS server from the DNS snap-in. Open the Forward Lookup Zones folder, and you'll see a folder whose name is simply ".", which, as you now know, is the root domain. Right-click that folder, choose Properties, and check that the zone type is Primary rather than AD-integrated; if the zone is AD-integrated, click Change next to the type and convert the zone to a standard primary zone. Then, in the Forward Lookup Zones folder, right-click the root zone and click Delete. Close the DNS snap-in, restart the DNS Server service, then reopen the DNS snap-in. The Forwarders and Root Hints tabs will no longer be grayed out.

As far as I know, the third uprooting approach works only on a standard primary zone. First, stop the DNS Server service, either from the GUI or by typing

net stop "dns server" 

at the command line. Then, edit the registry to remove the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSZones. subkey (the final period is part of the subkey). Restart the DNS service, and you're back in the public DNS hierarchy.

Disabling NetBT with DHCP
In "Life Without NetBIOS," August 2001, InstantDoc ID 21537, I reported on some of what I found when I disabled NetBT on my Win2K domain. To do that experiment, I manually configured the TCP/IP stacks on my Win2K boxes to disable NetBIOS—a labor-intensive operation. In that column, I mentioned that you can use DHCP to disable NetBIOS. In this column, I explain how. First, I'll give you the procedure step by step, then I'll explain what goes on behind the scenes.

To start, open the MMC DHCP snap-in. Under the icon for the DHCP server, you'll see a folder that represents your DHCP scope. (You'll likely have more than one folder if the DHCP server supports more than one scope.) In the scope's folder, right-click the Scope Options folder and choose Configure Options. Alternatively, if you want to disable NetBT on all your scopes, right-click the Server Options folder that appears below the server's folder, then choose Configure Options. (If Configure Options is grayed out, don't panic. Right-click the Scope Options or Server Options folder, then left-click it, and Configure Options will be active.)

The resulting Scope Options window has two tabs: General and Advanced. Click the Advanced tab. You'll see single-selection drop-down list boxes labeled User class and Vendor class. For User class, select Default User Class. For Vendor class, choose Microsoft Windows 2000 Options. In the Available Options area, select the Microsoft Disable NetBIOS option. In the Data Entry/Long text field, type 0x2. Click Apply, then close all remaining dialog boxes.

Now, go to any Win2K computer that receives its IP addresses from that DHCP server, open a command prompt, and type

ipconfig /renewipconfig /all

Assuming that your system is configured to take its NetBT cues from DHCP (which is the default behavior), you'll see a line in the Ipconfig /all output that says NetBIOS Over Tcpip....Disabled.

That's the procedure, but what does it actually do? DHCP and its options are standard across all OSs—DHCP isn't a proprietary protocol. But Microsoft and other vendors need to be able to offer client options that aren't in the DHCP standard. Client options let the administrator tell the DHCP server, "If you get a client with such-and-such characteristics, give it this setting."

A vendor class is a characteristic that the vendor burns into the OS—you can't change or, as far as I can determine, even view your system's vendor classes. However, you can view and control user classes from the command line by typing

ipconfig /setclassid * 

For example, suppose you're experimenting with disabling NetBT in a test lab and you want to disable NetBT only for the computers in the lab. You could go to the DHCP server and define a new user class called labcomputers: Right-click the server's icon and choose Define User Classes. Type Lab Computers in the Display name field, then type labcomputers in the right-hand side of the ID field. Finally, configure the Microsoft Disable NetBIOS option as I explained earlier (i.e., with a vendor class of Microsoft Windows 2000 Options and a user class of Lab Computers). Then, visit each test-lab computer, open a command prompt, and type

ipconfig /setclassid * labcomputers

The spelling and case of the class must match what you entered for the ID value when you created the user class.

Now, execute some Ipconfig /renew commands around your network and the test lab; you'll see that NetBIOS is disabled only on the lab PCs. One word of caution: User-class support seems a bit flaky on Win2K. For example, sometimes the /setclassid parameter doesn't overwrite the existing user class unless you first type

ipconfig /release

Furthermore, you should be able to type

ipconfig /showclassid *

and see your user classes. However, sometimes the response says you have no user classes. But if you type

ipconfig /all

the output will include the name of your user class. So, experiment a bit before you rely upon the /setclassid parameter.

Of course, this inconsistency is troublesome only if you employ user classes. The simple vendor-class—based approach that I described will work like a charm as long as you want to disable NetBT on all your Win2K boxes.