How DNS Works

DNS resources and tools to help you get connected

As a systems administrator, you might be responsible for connecting your company to the Internet, possibly for the first time. But before you can do so, you need to understand the basics of Internet addressing, find out how to get a Web address, and learn how to register your domain name. In "A DNS Primer," January 2000, Mark Minasi introduced the fundamentals of DNS. I will help you find resources for obtaining IP numbers and registering your domain name and provide practical information about DNS and its associated tools. (For more information about domain naming, see "Related Articles in Previous Issues," page 115.)

Obtaining Names and Addresses
The Internet Assigned Number Authority (IANA—http://www.iana.org) was historically the organization that doled out names and addresses. However, in 1993, the National Science Foundation (NSF) awarded to Network Solutions Incorporated (NSI—http://www.networksolutions.com) a 5-year contract that authorized NSI to operate the InterNIC (http://www.internic.net) name-registration service. At that time, InterNIC was the place that most people went to for a network identifier (NET_ID) or a domain name in the .com, .org, or .net namespace. When InterNIC assigned your IP address, you owned the address and could keep it even if you changed ISPs. Today, the process of obtaining addresses and of registering domain names has changed.

IP addressing in the modern era. InterNIC no longer assigns IP addresses and hasn't done so since about 1997. In the Western Hemisphere and some parts of the African continent, the American Registry for Internet Numbers (ARIN—http://www.arin.net) is now the IP number authority. The size of Internet routing tables was becoming unmanageable, so several years ago ARIN organized unused address space into Classless Inter-Domain Routing (CIDR) address blocks. ARIN assigns the CIDR address blocks, in turn, to ISPs or other regional number authorities, such as Réseaux IP Européens (RIPE—http://www.ripe.net) in Europe and the Asia Pacific Network Information Centre (APNIC—http://www.apnic.net). If you're in the United States, you need to coordinate with your ISP to obtain an IP NET_ID address from ARIN.

More than 50 percent of all possible Class C addresses are still available, but because the address supply is rapidly diminishing, getting a full Class C address is difficult. Instead, ISPs and ARIN distribute small address blocks and assign NET_IDs with as few as eight host addresses. IP number authorities assign the address blocks by using variable-length subnet masks (VLSMs), which provide a method of implementing classless addressing. A full description of VLSMs is beyond the scope of this article, but the sidebar "Subnetting and Variable-Length Subnet Masks" describes the motivation for using VLSMs and gives a VLSM example.

How can a company with several hundred systems operate with a mere handful of IP addresses? Companies might have many users, but generally they have only a few servers that require publicly visible IP addresses. Increasingly, organizations use private IP addressing internally and assign a public IP address to public servers. Companies might use the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 private addresses or Network Address Translation (NAT) to statically map the server's public address to an internal private address. When a client system communicates with the Internet, NAT dynamically and temporarily assigns the client a public address. If the number of clients that need addresses exceeds the number of available public addresses, Port Address Translation (PAT—aka NAT overload) provides the addresses. NAT and PAT address management occur transparently at the router or NAT server. To learn more about current address assignments, visit John Crossley's IP Network Index (http://www.ipindex.net/), which cross-references IP Class A, B, and C network numbers with network names.

Registering domain names in the Internet's commercial era. The NSF's contract with NSI expired in April 1998. Unfortunately, no one planned how to handle domain name requests after that date, so NSF has extended NSI's contract several times, most recently through September 2000. In 1998, the Internet Corporation for Assigned Names and Numbers (ICANN—http://www.icann.org) began creating a fair and efficient domain-name-registration system. Many factors influenced the formation of ICANN, and you can find a good description of its history and evolution at the National Telecommunications and Information Administration (NTIA) Web site (http://www.ntia.doc.gov/ntiahome/domainname). Although NSI remains the sole administrator of names in the .com, .org, and .net namespace, many companies, such as America Online (http://www.aol.com), Internet Names WorldWide (http://www.internetnamesww.com), and register.com (http://www.register.com), can register names in that space. You can find a list of all accredited name registrars at the ICANN Web site.

DNS Internals
DNS is a distributed database that contains host, mail server, name server, and other domain information. You must maintain a primary name server and at least one secondary name server for every Internet domain. When a client system on the Internet needs to find a server's IP address (e.g., a reader of this article surfing to http://www.win2000mag.com or sending email to [email protected]), the client sends a DNS query to its local name server. If the local name server doesn't have the necessary target server address information, the local name server sends a query to one of 13 well-known root name servers on the Internet. The query then proceeds to one of the target domain's name servers for final resolution. Many ISPs provide primary and secondary DNS service; others provide only secondary DNS service and require the customer to host the primary name server.

Examining DNS file structure will help you understand the name-lookup process. DNS information resides in simple text files called zone files, which contain information called Resource Records (RRs). The most common RRs are

Listing 1, page 115, shows an example zone file mapping host names to IP addresses in the fictitious example.com domain. In this example, the domain hosts Web, FTP, email, and name servers, and the ISP (ispexample.net) hosts the secondary DNS and backup mail server. The IP address in this example is actually a private IP address. So what do all these records mean? The SOA record includes the name of the primary DNS server for this domain and the email address associated with this domain's naming administrator; note that the record lists the DNS administrator's email with a period (.) instead of the at sign (@) because @ has special meaning in DNS files.

This resource record also contains five other parameters. First, a serial number identifies the version of this information and tells a secondary server that new information exists to download. Second, a refresh value tells the secondary name servers how often to check for updated information. Third, a retry value tells the secondary servers how often to reattempt connections to the primary server. Fourth, an expire value tells the secondary servers when the information in databases is old and unreliable. And fifth, a Time to Live (TTL) value tells a requester how long you can safely cache the information.

The NS records contain the names of the name servers for this domain. The first server listed is the primary name server because it's the server that the SOA record names. The MX records contain the names of the email servers for this domain. The number in front of the address is the preference value and is most useful when the domain has two or more email servers.

When a remote user sends mail to [email protected], the remote mail system looks up the MX record for the example.com domain. The remote mailer then attempts to establish an SMTP connection with the mail server that has the lowest preference value. Thus, an organization can specify multiple mail servers with the same preference level for load balancing, or specify servers with different preference levels to provide a backup. The A records contain the IP addresses to associate with each of the listed host names in the example.com domain. The CNAME record contains alias host names. In this example, the FTP and Web services are on the same server but have two different names that map to the same IP address. Using two separate names ensures that if the FTP service moves to another system, external users never need to know about the move.

Each domain contains another important zone file: the reverse lookup file. This file maps an IP address to a host name. The zone file for the fictitious 192.168.210.0 address space (assuming that this entire Class C address has one owner) might look like the file in Listing 2, page 116. The only new RRs in this listing are the PTR records, which associate an IP address with a host name.

You'll find DNS server software under a variety of names, depending on the OS you use. Windows NT simply refers to DNS, but UNIX calls the software named (i.e., name daemon) or Berkeley Internet Name Domain; BIND is the most common name. Although each DNS software package is slightly different from others, it's useful to understand RRs and file formats so that you know how the packages lay out domain name information. For information about products that let you provide a DNS service on an NT server, see the sidebar "DNS Resources," page 116.

All DNS software uses the same terminology to refer to DNS information, whether the software uses regular DNS text-file format or a proprietary-file format. Furthermore, although individual sites might not use UNIX-based DNS software, the major ISPs do, so you need to use the correct terminology when discussing DNS with your ISP.

Last but not least, UDP datagrams on port 53 carry DNS queries. DNS zone transfers between primary and secondary name servers use TCP on port 53. If you run the primary DNS server on your network and connect to an outside secondary DNS server, configure your firewall so that zone transfers can occur only between the designated name servers.

Tools to Examine DNS and Domain Information
The most basic tool you can use to search a domain name or IP number database is NSI's Whois. Although you'll find Whois on all UNIX systems and some Windows systems, accessing the database is easiest on the Internet. You can find NSI's Web interface to Whois at http://www.networksolutions.com/cgi-bin/whois/whois. Screen 1, page 116, shows a Whois query for the win2000mag.com domain. The response shows contact information for the domain, when the record was last updated, and the associated name servers (in preference order). You can use Whois to look up information based on domain names and contact names. Whois can also tell you whether a particular domain name is available.

Nslookup is a handy TCP/IP utility for examining the DNS database. This utility is a standard part of NT (and UNIX) systems, and versions of Nslookup for Windows 9x also exist. You can use the Nslookup utility as a test aid to examine DNS.

Figure 1 shows an example Nslookup session. As callout A in Figure 1 shows, the user invokes the program by typing the command nslookup. The program responds by listing the name and address of the user's default name server. The first command, Help, which callout B in Figure 1 shows, lists all Nslookup commands and functions. Callout C in Figure 1 shows that the user next enters host name www.win2000mag.com. The program responds by listing the host's IP address (204.56.55.202). The set type=MX command, which callout D in Figure 1 shows, tells the program to display MX information. The following command, Win2000mag.com, asks for information about the win2000mag.com domain. The program responds with the names and addresses of the domain's three mail servers (and two name servers). Callout E in Figure 1 shows the Set Type=SOA and Win2000mag.com commands, which tell the program to display SOA information about the win2000mag.com domain. Finally, the program responds with the SOA parameter information, as well as the names and addresses of the domain's name servers.

The NS host information that Nslookup shows (ns1.duke.com and ns2.duke.com) doesn't match the host information that the Whois lookup shows (ns1.rockymtn.net and ns2.rockymtn.net). This result is unusual but merely signals that the Whois database isn't synchronized with the name server information advertised on the Internet. Given this discrepancy, the display from nslookup is more definitive than the display from Whois.

In the past, Internet connections, IP addresses, and domain names were the responsibility of UNIX systems administrators. However, because NT represents a growing percentage of servers on the Internet, these details are important to systems administrators who have traditionally concentrated on the LAN. DNS is one of the most important aspects of your site's Internet connection. If you don't set it up correctly, your public hosts might be unreachable and your users might not be able to reach hosts on the Internet. If you want to know the nitty-gritty behind DNS, the industry-standard text is Paul Albitz and Cricket Liu's DNS and BIND, 3rd edition (O'Reilly & Associates, 1998). For NT-specific information, see Paul Albitz, Matt Larson, and Cricket Liu, DNS on Windows NT (O'Reilly & Associates, 1998).