Introduction to Microsoft DNS

Some people might ask, what is the Microsoft DNS and why should I use it? Well let's start out by telling you what it is not. First, the Microsoft DNS server is not a port of the Berkley BIND code (which is currently at revision 10.4 as of the writing of this paper). We made a conscious decision to not port the BIND code, but rather write our own code that was fully RFC compliant and compatible with BIND. We made this decision because we wanted to be able to easily add performance enhancements to the product. The Microsoft DNS server is also not the code that was shipped in the Windows NT Resource Kit. If you used that utility, you probably noticed that it had problems with zone transfers. The DNS server service in Windows NT 4.0 is a complete rewrite and is not just a bug-fixed version. Rest assured that in the DNS included with
Windows NT 4.0, RFC compliance has been thoroughly tested and it all
works as defined, including zone transfers.

Now let's talk about what the Microsoft DNS server is. First and foremost, the DNS server in Windows NT 4.0 is an RFC compliant implementation of DNS. If there is a required feature in an RFC that is not found in the Microsoft DNS product, this would be considered a bug.

Because Microsoft DNS is an RFC compliant DNS server, it creates and uses standard DNS zone files and supports all standard resource record types. It is interoperable with other DNS servers and includes the defacto standard DNS diagnostic utility—NSLOOKUP. Microsoft DNS also has many features above and beyond those specified in the RFCs, such as dynamic update through tight integration with WINS and easy administration through the graphical administration utility called DNS Manager.

With the Microsoft implementation of DNS, network administers can turn off the legacy DNS systems in favor of a Microsoft Windows NT implementation. They can remove any static entries for Microsoft-based clients in legacy DNS server zone files in favor of the dynamic WINS/DNS integration. For example, if a non Microsoft-based client wants to get to a Web page on an HTTP server that is DHCP/WINS enabled, the client can query the DNS server, the DNS server can query WINS, and the name can be resolved and returned to the client. Previous to the WINS integration, there was no way to reliably resolve the name because of the dynamic IP addressing.

The following figure shows how a non-Microsoft-based client might find a machine named "scottsu1.microsoft.com" which is running Microsoft Internet Information Server (IIS) which has a dynamically allocated address from DHCP and which has registered with WINS.

Also, as mentioned previously, the server running Microsoft DNS has a graphical user interface DNS Manager that allows for easy administration of any other Microsoft DNS server on the network via RPC (similar to the way other Windows NT administrative utilities such as Server Manager and Event Viewer work). The administrative UI also contains a zone wizard that enables someone less familiar to DNS to be successful in creating zones and zone database files. Keep in mind that you cannot administer non-Microsoft DNS servers with this administrative tool.

It's important to note that the Microsoft DNS server can easily use the database, boot, cache, rev and other files from any other DNS server implementation (that is UNIX or other Windows NT DNS implementation) as long as that DNS server is RFC compliant. All that needs to be done to port the files over to Microsoft DNS is to change the file names and locations in the boot file.

The Microsoft DNS server can also be a primary or secondary to any other operating system (or other vendors Windows NT implementations). This makes it easy to begin to migrate away from a UNIX DNS-based solution to the Microsoft-based solution.

The next section will walk you through the setup of a Microsoft DNS server and explain the parameters required for a client resolver to work.