Microsoft’s implementation of DNS has always varied from the original. With Dynamic DNS around the corner in Windows 2000, you’ll want a clear understanding of what those variances are.

DNS Dichotomy

Microsoft’s implementation of DNS has always varied from the original. With Dynamic DNS around the corner in Windows 2000, you’ll want a clear understanding of what those variances are.

• By Michael Chacon
• January 01, 1999

DNS is DNS is DNS—except where Microsoft is concerned. The Microsoft way is often referred to as planned proprietary development, meaning that Microsoft avoids standards in order to create confusion. I don’t think we can fully resolve that issue here, but it does beg a bigger question. Should you follow existing standards that prevent you from moving forward, or should you try to create new standards to solve your problems and move ahead—and in the process, leave old standards behind? The answer is both, but be prepared to be slammed by your competition on one side and dragged forward by the needs of your customers on the other.

A good example of this dichotomy is the implementation of the Domain Name Service (DNS) in Windows NT 4.0. It will continue to sharpen as Windows NT 5.0 (now Windows 2000) unfolds.

As you might have guessed by now, Microsoft’s version of DNS isn’t a straight port of the Berkeley BIND DNS code. However, it’s fully RFC-compliant and compatible with BIND implementations. Furthermore, Microsoft has said that if there’s a required feature in a DNS RFC that isn’t in the Microsoft DNS, it’ll be considered a bug and resolved.

Why the Difference?

The main reason Microsoft’s DNS has non-standard enhancements is because of our friend NetBIOS. NT uses NetBIOS names to identify workstations uniquely, and these names need to be resolved to IP addresses for network communication. Standard IP uses binary numbers to communicate, and these numbers can logically be mapped to HOST names for ease of use. The systems are conceptually similar to each other, and Microsoft needed to be able to bridge these differences. (The NetBIOS difference will begin to melt away as Windows 2000 is deployed—I’ll deal with this later in the year.)

The other reason for the non-standard enhancements is that Microsoft wanted to store DNS information in the registry rather than just in the flat ASCII files that traditional DNS implementations use. In the current DNS implementation, the configuration information is stored in the Registry, but the meat of the DNS configuration information is in the zone.dns and cache.dns files under %systemroot%\system32\dns. With Windows 2000, both the configuration information and zone information is stored in the Directory Service. The administrator will have the option of using the AD replication to transfer zone information, or to use traditional zone transfers. The ASCII files can be edited to manage the DNS configuration information, but Microsoft recommends you use the DNS Manager GUI tool to configure the DNS. However, if you do edit the files manually, you’ll need to stop and start the DNS service in order for the changes to take effect. You can also modify the registry to tell the DNS to use the traditional configuration information boot files for initialization instead.

Installing the Microsoft DNS server is simple, as with most Microsoft services. You must, however, make sure you’re within the bounds and authority of any existing DNS domain structure in your organization. Check with your internetwork administrator before even bringing up a test DNS on your production network. Once you’ve gotten approval, the next step is to make sure that your TCP configuration reflects the information that you want included in your DNS installation. This is because the default information for your DNS will be taken from those tabs that you never bothered with before, as shown in Figure 1.

Figure 1. Check your TCP/IP configuration before beginning your DNS installation. This information will be entered automatically into the Resource Records in the new DNS, so you want it to be accurate.

As you can see on the DNS tab of my TCP/IP Properties page, I have information that specifies my host name and domain. I use Cox Cable as my Internet provider, and my workstation is a node on the Cox network. So, if I want to install a DNS on this machine that communicates with Cox, I must submit to their authority. I’d then be able to create subdomains on my network below orngl.occa.home.com and provide resolution locally. All of the information listed in Figure 1 will automatically be entered into the Resource Records in the new DNS. If the information in your configuration isn’t what you want reflected in your DNS, you need to change it before you configure your DNS server.

After you install the DNS service from the Control Panel | Network | Services applet, the DNS Manager will be added to your Administrative Tools menu. You use this tool to complete the configuration and on-going management of your DNS server. When you first bring up the management tool, there won’t be any servers listed. Because there aren’t any records created yet, the only resource record that will be entered is the cache record as shown in Figure 2. As I discussed last month (see "Let's Just All Get Along: DNS Fundamentals"), this record lists all of the DNS Root servers. You can add new servers under the DNS | Add menu and either use the IP address of the server or the ComputerName.

Figure 2. The DNS Manager helps you configure and manage your DNS server. When you first install the DNS Manager, because you haven’t created any records yet, it’ll only display the cache record.

When you add the new zone for your DNS server from the DNS | New Zone menu, you’ll be presented with a series of basic dialog boxes. The main decision here is whether to add a primary or secondary zone. You may remember that a primary zone holds the master copy of the information regarding the DNS server. A secondary zone is a copy of that data that’s used for backup and load balancing. When you’ve added the new zone, the basic resource records will have been created for you as shown in Figure 3, based on the information in the TCP/IP properties configuration page under the DNS tab.

If you select the zone and right-click on it, it brings up the properties page. This page displays all the configuration information for this zone, as shown in Figure 4.

Figure 3. When adding a new zone for your DNS server, you must decide whether it will be a secondary or primary zone. Once you’ve added the zone, the basic resource records will be created for you.

Figure 4. The zone properties page shows all the configuration information for a given zone. To get to this page, right-click on the zone from the DNS Manager server list.

Now that we have a basic operational zone created, we need to add the resource records. These are most commonly “A” type records, which map host names to IP addresses, and “MX” type records which designate mail servers that should receive Internet mail for the domain. There are a number of other types as well.

Most of what I’ve said so far is standard DNS configuration information. The only difference is that Microsoft has written a GUI—the DNS Manager—to access the DNS resource records. With a standard DNS, all this information would have been entered into each individual resource record with a text editor.

You can edit the configuration file manually if you desire, but make sure that the DNS service is stopped when you do. The changes will be put into effect when you restart the DNS service. You can also flush changes, either in memory or in the Registry, back to these files from the Microsoft DNS Manager by choosing the DNS—Update Server Data Files menu.

DNS and WINS Integration

The biggest difference between Microsoft’s DNS and standard DNS is that Microsoft’s DNS is integrated with WINS. (WINS | Windows Internet Naming Service | matches NetBIOS names to IP addresses.) This is because of Microsoft’s aforementioned use of NetBIOS to identify NT workstations so that other workstations, such as those running Unix, can locate NT resources through the DNS server. This is accomplished by the addition of a WINS resource record in the Microsoft DNS.

To configure this integration, open the DNS Manager and select the WINS Lookup tab on the zone properties page. Next, select the Use WINS Resolution box and enter the IP address of the WINS servers that you want to use for resolution. This will enable the integration for the entire zone. If you have multiple zones in your system, each zone needs to have this configured before proper resolution can take place.

With these configurations in place, a DNS resolver (or client) could look for worksta12.office.com in DNS and find it through WINS. Since WINS is a flat namespace, the DNS would handle the resolution through the domains and then pass the request for the flat worksta12 name to WINS. In turn, WINS will pass the IP address back to the DNS server, which would cache it for future resolutions and pass the IP address back to the requesting machine through the normal DNS process. For this to work efficiently, you must make sure that the host names for the machines you want resolved through this process match the ComputerName.

Microsoft DNS has other WINS features as well, including the ability to provide reverse lookups for WINS in a similar manner to the way they are provided for regular host names with PTR records (in other words, looking up the Computer Name for a given IP address). There’s also a WINS-R record that uses the NetBIOS node adapter status lookup for any reverse lookups in the zone that aren’t statically defined.

You can have a combined pure BIND DNS working with the Microsoft DNS and provide seamless service. Simply make the appropriate entries in the Start of Authority records for the DNS servers to communicate.

Keep in mind, however, that the added functionality of the Microsoft version of DNS will work only within the zone enumerated within the Microsoft DNS service. Many people are reluctant to use the Microsoft DNS in networks because of the historical Unix administration of DNS. That is, in larger IS shops the staff that manages the DNS today typically uses a Unix machine for host resolution, and these people usually aren’t the same as those who manage the NT networks. In many cases, there’s animosity between the Unix network administrators and what they may consider the “departmental” LAN support staff. This will be as much a political issue as a technical one.

The next evolutionary step is Dynamic DNS, which will be used for Windows 2000. Dynamic DNS will allow the automatic registration of hostname to IP address mappings in the database and minimize the need to make manual edits. This will mean as clients start up and receive their TCP/IP configuration from a DHCP server, a DNS entry that maps the host name to the allocated IP addresses will automatically be created.

Essentially, the DNS of tomorrow will have the functionality of NetBIOS-based WINS, but with the interoperability of the Internet DNS system. As I’ve mentioned in previous columns, the whole NetBIOS dependency goes away in a pure Windows 2000 environment. In addition, Active Directory needs DNS to locate resources. Since Microsoft will be one of the first to implement Dynamic DNS, this will put even more pressure on administrators to consider Microsoft’s DNS. As Windows 2000 gets closer, I’ll cover these changes in detail.