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.
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.