Integrating and Administering DNS

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

LISTING 1: Sample WINS Lookup Record

sakellariadis.dom file @ IN WINS patmos.sakellariadis.com patmos.sakellariadis.com. IN A 204.241.138.10 samos.sakellariadis.com. IN A 204.241.138.20

LISTING 2: Example SOA Record

@ IN SOA patmos.sakellariadis.com. spyros.patmos.sakellariadis.com. ( 996050209 ; serial number 10800 ; refresh 3600 ; retry 691200 ; expire 86400 ) ; minimum TTL

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  [1]  2  Next