NT 4.0 makes DNS manageable
[Editor's Note: This article is part 2 of a two-part series on
implementing Domain Name System (DNS) under Windows NT. Part 1, "Configuring
and Administering DNS," in the August issue explained the basic DNS
components and settings under NT 4.0.]
By adapting BackOffice services for use with the Internet, Microsoft is
paving the way for new features and functionality in many products. One step in
this direction is taking a valuable Unix feature--Domain Name System (DNS)--and
expanding on it.
Part 1 of this series explained where DNS comes from, how it works, and
what it consists of. This article shows how the new DNS feature in Windows NT
4.0 works with the Windows Internet Name Service (WINS) and how a new type of
Resource Record (RR), the WINS lookup record, helps solve some problems
associated with name resolution. This article also demonstrates how the new DNS
Manager tool lets you configure and administer DNS. Once you understand how DNS
and WINS interact and how to take advantage of the DNS Manager, you'll be able
to tackle DNS on your own--under Windows--without the help of your Unix friends.
Integrating DNS with WINS
Part 1 of this series described the
painful process of manually resolving remote names on a TCP/IP network before
the advent of DNS and how DNS simplifies this process tremendously. DNS often
runs on a Unix platform, and a DNS administrator has to continually update DNS
configuration files to add new names.
Microsoft took the concept of DNS a step further by introducing a
proprietary name resolution method called WINS. WINS is similar to DNS but has a
database of names and corresponding addresses that WINS dynamically updates, and
WINS works only on a Microsoft-based TCP/IP network.
For example, a multiplatform network can have a Unix-based server to handle
DNS requests and an NT-based server to handle WINS requests. This network
configuration means you spend a lot of time administrating two separate name
resolution methods. NT 4.0 cuts this administrative overhead by integrating both
name resolution methods.
WINS and DNS both participate in resolving computer (NetBIOS) names and host
names in a typical Windows environment. (For a detailed description of resolving
these types of names, see the sidebar, "Name Resolution," on page
126.) Critics like to point out that this arrangement can lead to problems
involving static DNS name registration and Dynamic Host Configuration Protocol
(DHCP)-assigned IP addresses. Integrating WINS and DNS in NT 4.0 helps solve
these problems.
The first problem involves clients trying to reach a server in a network
where the DNS administrator is behind schedule on updating the DNS. Consider the
network in Figure 1. Suppose Judy tries to ping a recently installed host
(spots.sakellariadis.com) on the corporate network. Judy's computer
(judy.sakellariadis.com) checks her lmhosts and hosts files for a
spots.sakellariadis.com entry. If Judy has no entries in her lmhosts or hosts
files and therefore doesn't know the host's IP address, she queries her DNS,
samos.sakellariadis.com. Judy's request will ultimately reach
patmos.sakellariadis.com, the authoritative Domain Name Server for the
sakellariadis.com domain. If the DNS administrator hasn't yet manually updated
the configuration files for sakellariadis.com, Judy's DNS request fails. If Judy
is a Windows client, she has one other option--she can query her WINS server on
wins1.sakellariadis.com. If this WINS server has a mapping (a correlation
between the physical IP address and computer name) for \\spots, Judy can ping
spots.sakellariadis.com.
Another problem involves networks that manage IP addresses with DHCP. If
spots.sakellariadis.com has a static IP address of 204.241.138.55 and the DNS
administrator manually creates an address (A) record in the configuration file
to reflect that address, Judy can ping spots.sakellariadis.com. However, if
\\spots uses DHCP, the IP address is dynamic and can change. So when you're
using DHCP, don't use DNS, because DNS name registration hard-codes IP addresses
and relies on manual intervention for updating.
The WINS Lookup Record
In addition to the basic RRs (A, PTR, NS,
SOA, CNAME, MX, MB, MR, MG, HINFO, TXT, MINFO, RT, RP, X25, ISDN, WKS, AFSDB)
that the DNS configuration files support, NT 4.0 DNS includes a WINS lookup
record. It is specific to NT and solves the problems just described by letting
DNS query WINS. Listing 1 shows a sample WINS lookup record.
As the place.dom sample file that Microsoft provides in the \system32\dns
directory states, "the presence of a WINS record at the zone root instructs
the name server to use WINS to look up any request for A records for names which
are direct children of zone root, and which do not have A records in the zone
file." This statement has major implications for what happens when you
register static DNS names.
Imagine that Judy tries to reach felix.sakellariadis.com. If she doesn't
find a listing for felix.sakellariadis.com in her lmhosts or hosts files, she
queries her DNS, samos.sakellariadis.com, which queries
patmos.sakellariadis.com. So far, she can reach only the DNS at
patmos.sakellariadis.com looking for an A record for felix.sakellariadis.com. If
that A record is not there, Judy's request fails.
If the DNS administrator of patmos.sakellariadis.com adds a WINS lookup
record for wins2.sakellariadis.com to the configuration files, DNS can query the
WINS database for felix.sakellariadis.com and respond to Judy's request. If
felix.sakellariadis.com is registered in the corporate WINS database on
wins2.sakellariadis.com, Judy can ping felix.sakellariadis.com successfully.
Notice the subtle difference between this WINS approach and the host name
resolution example in the sidebar on page 126. With host name resolution, if DNS
doesn't have an A record for felix.sakellariadis.com, Judy tries her WINS
server, wins1.sakellariadis.com, which doesn't have a clue.
Now, if DNS on \\patmos doesn't have an A record for
felix.sakellariadis.com, \\patmos tries its registered WINS server,
wins2.sakellariadis.com. This redirection takes the burden off Judy's WINS
server and puts the responsibility on the sakellariadis.com corporate network
WINS server where it belongs.
This approach solves the first problem of the DNS administrator not
updating the name registration. By removing most A records from the Domain Name
Server and pointing the Domain Name Server to the local WINS server, we can make
the Domain Name Server work as if it's being dynamically updated with
host names.
This approach also solves the second problem associated with DHCP-assigned
IP addresses. Because DHCP and WINS are tightly coupled, the WINS server updates
the WINS database when the DHCP-enabled client's IP address changes and the
system picks up this change when someone queries DNS for a name not in the DNS
database.
Microsoft's sample files that install in the \system32\dns directory when
you configure DNS contain several caveats about the complexities of setting up
zone transfers to secondary Domain Name Servers running BIND on Unix. These
files also contain warnings about querying subdomains and using secondary Domain
Name Servers with different WINS servers. If you work in environments where
these issues are vital, read the sample files carefully.
Previous
Register
