DNS Strategies

Connecting IP Addresses with Host Names--and Vice Versa

DNS Strategies
The Domain Name System (DNS) is a basic Internet facility. Whenever you use a name to refer to a host computer on the Internet, a DNS server must translate that name to the host's IP address. Before you connect a subnetwork to the Internet--whether it be one machine or 1000--the implications to DNS should be carefully understood.

Although DNS administration always requires care and attention to detail, it shouldn't require as much concern as it does for Windows NT networks. But Microsoft doesn't yet include a functional DNS server in NT. Therefore, the NT administrator must deal with basic choices about DNS implementation as well as ordinary configuration and design issues.

What Is the Domain Name System?
First, DNS is not the Windows Internet Name System (WINS). Although there is a partial overlap of functionality, the two systems have some basic design differences. DNS is a mostly static database while WINS is highly dynamic. More importantly, DNS is a universally accepted Internet standard; at present, WINS is not. Regardless of their relative merit, however, keep in mind that for name translation within the global Internet today, DNS is the standard and WINS is irrelevant.

Before DNS became widespread, host computers maintained host-table files that contained pairings of host names with IP addresses. A name-to-number association had to be included in the table for every new host that local users wanted to refer to by name. (In early ARPAnet days, this was not a big problem; there were only a few dozen host machines in the network universe.) Today, however, a system based on the continued maintenance of a name-to-address mapping file with a record for every host on the Internet would soon be overwhelmed. The host-table approach just isn't scalable.

Domain names are the names used to refer to hosts on the Internet. They are formally structured to ensure that every name is globally unique and to facilitate a simple translation method. Domain names are structured hierarchically so that they can be stored and maintained in a distributed, hierarchical administrative system.

Hierarchical naming with delegated authority is not an exotic idea. Most geopolitical place names are chosen this way. For example, the United States contains 50 states, no two of which have the same name. Within each state, however, counties, cities, and towns have names that while unique within their state are not unique within the entire US. Each administrative unit is free to name the places within its own boundary of authority--names need only be locally unique. As Concord, California, USA and Concord, New Hampshire, USA are distinctly named, so are the domains cs.berkeley.edu and cs.umass.edu.

At the top of the hierarchy is the root domain. Its sole purpose is to contain the top-level domains. The root domain's formal name is the null, or empty, string. A fully qualified domain name is one in which the entire hierarchical name is explicitly given. For example, within the Berkeley computer science department, a host may be referred to as fred, while its fully qualified name is fred.cs.berkeley.edu. (with a trailing period and null string). The period and null string at the end of the name represent the root domain, which contains the edu domain (see Figure 1).

Anyone familiar with Internet host names will recognize the top-level domain names: com, edu, gov, us, uk, fr, etc. There are two general types of top-level domains. The first is classified by the attributes of the organization that "owns" the domain: Commercial businesses fall in the com domain; non-profit organizations go in the org domain; degree-granting educational institutions are under edu; etc. The second includes those domains that are classified along national lines (e.g., uk for United Kingdom; fr, France; si, Singapore; etc.). These domains are international in application.

The domain cs.berkeley.edu can be considered as the cs subdomain of the berkeley.edu domain. The formal DNS specification does not define subdomains, but the idea is useful in pointing out the relationships among domains. Often--but not always--the authority to manage naming within a subdomain will be delegated to a different administrator. For example, the Berkeley network "czar" in charge of naming within the university as a whole might delegate the naming authority for cs.berkeley.edu to an administrator within the computer science department.

Sometimes, the authority that manages naming within a domain also manages names within some of its subdomains. For example, the Berkeley network czar may not delegate to all subdomains (e.g., admin.berkeley.edu). A zone of authority is defined as a domain plus all its subdomains minus those subdomains over which authority has been delegated to another administrator.

To enhance performance and availability, each zone must have more than one authoritative name server. This can create the common-data maintenance problems that arise when more than one "master" database must be kept accurate and timely. A master name server can initialize the database for each zone it maintains either from a local data file or from another master name server. In the latter case, the secondary master will ask the primary master where the database is maintained to transfer an entire zone's information via a TCP connection. The information is recorded locally in a data file to be used later in case a zone transfer cannot be completed.

Regardless of which DNS strategy is adopted for primary DNS, secondary DNS should be arranged with a remote site. Such arrangements can usually be made with Internet Access Providers (IAPs), other groups within a large organization, or other sites willing to arrange a secondary DNS swap (i.e., to handle each other's secondary DNS).

The Fundamentals
There are several different types of records within DNS. The data items maintained within DNS are called Resource Records (RRs). There are several types of RR, corresponding to the basic (and more esoteric) types of queries fielded by a domain server.

A Zone Definition/Start of Authority (SOA) record defines the email address of the zone administrator for the current zone and parameters affecting the rate at which secondary masters query primary masters for potential changes.

An Address (A) record maps a domain name to an IP address. Each host can have more than one IP address, so there can be more than one A record for a particular host name within a zone.

A Mail Transfer (MX) record is used to help deliver Internet mail.

A Reverse Pointer (PTR) record lets you determine the host's name from its IP address. This is the reverse of the usual translation.

A Canonical Name (CNAME) record defines an alias. By convention, the World Wide Web server for a domain, say, eff.org, can be found at a host named www.eff.org. Similarly, its FTP server might be found at ftp.eff.org. These services may well be on the same host computer. CNAME records enable both of these names to refer to the same host.

Several RR types provide additional information about host computers (HINFO), responsible persons (RPs), and general text information (TXT). It's a security risk to make host descriptions and administrative information available to any Internet questioner. In addition, older versions of the Berkeley Internet Name Domain (BIND; e.g., on remote secondary servers) cannot always transfer zones properly, including some of these RRs. So, it's a good idea to avoid using them unless you specifically need them.

Handling DNS Requests
When a client requests a name-to-IP-address translation, the local DNS server checks its cached data to see if it already has the address. (Local host names are always in the cache.) If the cache does not have the address, the server--perhaps making some default assumptions about a partially qualified name--locates the primary or secondary server for the domain. If necessary, the local server goes all the way to the DNS server for the top-level domains, such as com or edu. The top-level server will point the local server to the second-level server, and so on, until a server is found that authoritatively translates the name.

When a mail-transfer agent (MTA) receives a piece of mail, it examines the address. If the address is local, the mail is immediately delivered. If the address is not local, the MTA must determine where to send the mail. Neglecting the fine points, the MTA requests mail-exchange information for the destination from its DNS server. The server usually returns more than one priority-ranked mail-handling host name (MX record). The MTA forwards the mail to the highest-ranking mail handler that responds. This process is then repeated until the mail arrives at the recipient's mailbox.

For security and other reasons, you may need to translate an IP address to its corresponding host name. This is more difficult than it may appear. Reverse DNS reduces the 32-bit IP address to a kind of synthetic domain name, which then can be translated in the usual way. For example, suppose the IP address (in customary dotted-octet notation) that you need to translate is 204.187.29.3. Reverse DNS inverts the address and appends the domain name, in-addr.arpa. The end result, 3.29.187.204.in-addr.arpa, can be put through the normal name-to-IP-address translation.

Most DNS implementations try to cache as much data as possible due to the network overhead involved in translating a domain name. Query and response packets are exchanged with one or more remote name servers for each domain resolution request. After a DNS server has been running for some time, its cache contains the answers to the most commonly asked domain system queries. Shortcuts to answers of less common queries are also available. For example, if ftp.cs.berkeley.edu is frequently the target of FTP connections, its IP address is kept in the local cache and so is the IP address of the name server for cs.berkeley.edu. Therefore, a much less common query for the mail-exchange records of obscure.cs.berkeley.edu will be directed to the authoritative server immediately.

The current crop of native NT DNS servers are clones or directly ported versions of existing UNIX BIND implementations, probably the oldest--and certainly the most popular--implementation of DNS. To configure a name server on an NT system, you must only master the common BIND configuration directives. The actual name server program in most BIND packages is called NAMED (pronounced name-dee), or something like that (in MetaInfo's NT version, the program is NAMED32.EXE). The BIND database consists of a boot file (NAMED.BT in the MetaInfo version) which contains pointers to the zone definitions; a data file for each zone; and a hints file, which--for misty historical reasons--is improperly called a cache file (the cache command points to the file that tells BIND where to find the top-level servers).

DNS Strategies
There are three broad strategies for setting up DNS: external, native, and Resource Kit. The external strategy is simple and often best: Avoid the issue, and rely on a third-party vendor to provide DNS service for your domain. If yours is a subdomain of a larger domain within your organization, you can probably leave DNS to a higher-level authority that specializes in providing it. Organizational security issues usually entail consulting with such a specialist group. If an external IAP provides your Internet connectivity, it can probably handle your DNS as well.

The advantage of in-house DNS is flexibility and control. When outsiders make changes to your domain--new hosts, changed IPs, new aliases--they may be untimely and error-prone, and they may require a processing fee. If your local network is entirely made up of Windows NT (and Windows, Windows for Workgroups, or Windows 95) hosts, a native NT DNS strategy will be less expensive and less complex from an administrative point of view.

NT is not offered as a fully Internet-ready operating system out of the box. DNS is not yet a standard component. Microsoft includes a beta DNS implementation in the Windows NT 3.5 Resource Kit (see the book review on page 59). It is a recoded BIND clone, not based directly on any existing source-code distribution. Microsoft warns against its use except for testing. This warning should be taken seriously.

It is arguable whether the Resource Kit beta should be called beta software. Ordinarily, beta software includes all the features and capabilities planned for the final release. This is not true for the Resource Kit beta. Among other things, it reportedly can't act as a secondary server, and it doesn't understand some boot-file command lines, such as forwarders. I expect that most of these features will be part of the final release.

The Windows NT 3.5 Resource Kit is freely available for downloading at ftp.microsoft.combussyswinntwinntpublicreskitt35i386

I386. exe. Keep in mind that it requires 7.135MB of disk space. Undoubtedly, Microsoft's DNS server will be improved. But for now, a production NT DNS strategy must rely on third-party software.

MetaInfo, Inc. has DNS 1.1, its NT port of BIND. The product, in its current form, has been performing well for several months for many beta testers. Facilities to simplify installation have recently been added. In addition, a new Control Panel applet allows direct control of query and statistical/debugging logging. DNS 1.1 handles UNIX BIND database files with little, if any, modification. The product is complete, RFC-compliant, and stable. However, nothing is perfect. DNS 1.1 costs $400 per server license.

The product of a Montreal software developer, FBLI DNS is a newer, cheaper BIND port for NT. It is based on the most recent BIND, version 4.9.3. Because it's new, it doesn't have the track record of the MetaInfo product. Currently, FBLI DNS lacks a Control Panel interface. But at a quarter of the price, the cost-conscious or casual domain administrator must consider it.

DNS is not rocket science, but avoiding configuration errors and maintenance problems (which can be difficult to diagnose) demands care and attention. A diagnostic-probing tool, such as nslookup, is essential to diagnose DNS problems. Several versions of nslookup exist for NT, the best of which is the direct NT BIND port that accompanies MetaInfo's DNS 1.1. It is apparently identical to the powerful UNIX version. Another popular probing tool is dig, but I couldn't find an NT version for it at press time.

Other troubleshooting tools check DNS configurations for inconsistencies and other errors. Although one of the best tools, dnswalk, is written in Perl (and, thus, is amenable to NT conversion), it uses dig to do its DNS probes. Fortunately, you can use DNS debugging tools remotely, so you can use any Internet-connected UNIX system with the tools installed to explore problems.

Three Options
DNS is a critical Internet service. At press time, it is not a production NT facility. An NT systems administrator needing to set up DNS can choose from three options:

Although most NT users prefer native Windows NT solutions, any one of these three options may fill your needs.

References

1.Albitz, Paul, and Cricket Liu, DNS and BIND, O'Reilly & Associates, 1992. (Indispensable to anyone needing to understand, configure, or troubleshoot DNS; http://www.ora.com/gnn/bus/ ora/item/dns.html).

2.Lottor, M., RFC: Domain Administrators Operations Guide (ftp.ds.internic.net rfcrfc1033.txt).

3.Romao, A., RFC: Tools for DNS Debugging (ftp.ds.internic.netrfcrfc1713.txt).

4.Salamon, Andras, DNS Resources Directory (What all special-interest URL indexes should be: easy to navigate, well organized, and complete; from this URL, you can find everything on-line about DNS; http://www.dns.net/dnsrd/).

5.Stahl, M., RFC: Domain Administrator's Guide (ftp.ds.internic.netrfcrfc1032.txt).

The BIND masters' mailing list is at [email protected]. The DNS newsgroup is comp.protocols.tcp-ip.domains.