\[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.
GUI DNS Administrator
NT 4.0's new GUI DNS administration tool,
the Domain Name Service (or System--DNS) Manager, which you invoke from the
Administrative Tools group, puts a graphical face on the cryptic DNS
configuration files. The DNS Manager represents these obscure DNS configuration
files in an easy-to-understand manner--intuitive enough to make any Unix zealot
green with envy. The DNS Manager is a remote procedure call (RPC)-based tool
that requires a trusted connection to work. With the DNS Manager, you can
remotely administer DNS by viewing and editing the boot configuration of any
Domain Name Server on your network.
Part 1 of this series showed how you manually configure the DNS boot file and the configuration files. This article looks at how the DNS Manager lets you maintain the boot file and the configuration files and examines some RRs discussed in Part 1.
The boot File
When you install DNS in NT 4.0, the installer puts
an icon for the DNS Manager in the Administrative Tools group. When you bring up
the DNS Manager for the first time, you need to register the IP address of any
server that is running DNS and that you want to administer. This procedure is
similar to how you register a server in the SQL Server 6.0 Enterprise Manager or
the Exchange Server Administrator tool. Select New Server from the DNS menu, and
enter the Domain Name Servers' IP addresses. Screen 1 shows the addresses for
two Domain Name Servers, \\patmos and \\samos.
The left side of the DNS Manager represents the DNS boot file. Part 1 of this series showed the various entries you add to the boot file to tell the DNS service that it is primary or secondary for a domain, what the configuration files were, etc. In the DNS Manager, you enter this information in an intuitive dialog.
If you double-click on one Domain Name Server name in Screen 1, you see a list of the zones that server services. Screen 2 shows an expanded version of the \\patmos server. This server is the primary Domain Name Server for six zones: sakellariadis.com, paradigms.com, and four reverse-arpa domains. This server is also a secondary Domain Name Server for one zone, aegean.com, represented by the icon with an S superimposed on the globe.
Adding a new zone to the DNS used to involve adding a line to the boot file. Now you just select New Zone from the DNS menu. Screen 3 shows the Create new zone wizard.
To create a new primary or secondary zone, you simply type a new zone name in the Create new zone wizard. You can create a secondary zone by putting your mouse on the hand icon in the wizard dialog and dragging the icon onto a primary zone on the left side of the DNS Manager. At first, I had assumed that the hand icon in the box at the bottom of Screen 3 was an illustration, and I spent quite a while looking for a similar icon on my screen to drag to the target location, then I realized I just needed to click that icon.
If you select the Domain Name Server's IP address from the left side of the DNS Manager, you see WINS resolution and direct DNS queries on the right side that show how often the server has responded to requests. For example, Screen 4 shows only a few hits on the \\samos Domain Name Server from \\tadpole and \\samos. These statistics let you evaluate the load on the DNS server and debug problems with WINS or recursive queries. The current version of DNS doesn't export counters to the NT Perfmon.
Resource Records
Part 1 of this series discussed the laborious
manual process of adding RRs to the domain configuration files. The DNS Manager
makes maintaining these RRs easy.
If you select a zone from the left side of the DNS Manager, you can view its associated RRs on the right side, regardless of whether you highlight a primary or a secondary zone. (If you look at a secondary zone, the records are read-only--for example, you might want to view but not modify these secondary records to see whether the zone information has been updated.) A list box in the right side of the DNS Manager lets you view all the records or only a subset such as the A records. Screen 5 shows the A records in the sakellariadis.dom file for zone sakellariadis.com.
As Screen 6 shows, you can add a new A record by selecting New Host from the DNS menu. If you use the DNS Manager to add a new A record, it appears in the Zone Info on the right side. The DNS Manager will even add the record to the database file on the disk.
By selecting New Record, you can choose what type of RR to add to the configuration file. Screen 7 shows the New Resource Record dialog where you can add new RRs. The New Resource Record dialog shows the supported record types in the scroll box on the left.
When you select a record type from the left of the dialog, the appropriate fields appear on the right. A check box lets you automatically create the associated address-to-name record (the PTR record in the reverse-arpa configuration file). Veteran DNS administrators often have horror tales about forgetting the PTR records in the reverse-arpa files, so this feature is a nice addition.
As Part 1 explained, the Statement of Authority (SOA) RR can be confusing because of its cryptic structure. Listing 2 shows an example SOA record for the sakellariadis.com domain. The DNS Manager takes this cryptic structure and presents the SOA information in a dialog that's easy to understand. Screen 8 shows the DNS Manager entry for this SOA record.
Features
Each feature in the DNS Manager is well laid out, but
context-sensitive Help is noticeably absent. However, the Help file that comes
with the DNS Manager is excellent and is the best of the three or four DNS
tutorials I've seen.
Microsoft has added many other features to DNS in NT 4.0. These features range from solutions for problems you rarely encounter to features that are critical to every heterogeneous environment but beyond the scope of these articles. This series shows that Microsoft has become a significant player in the DNS environment. Whether Microsoft's DNS service can supplant Unix's remains to be seen. Given Microsoft's track record and its declared strategy of adapting BackOffice services for use with the Internet, I'm putting my money on this being a robust DNS implementation.
