How DNS Works:
What It Means to the Customer Getting Connected

This article is targeted at the system or network administrator responsible for a company getting connected to the Internet, possibly for the first time. This article will discuss domain name registration and obtaining IP numbers, as well as provide some details about the Domain Name System (DNS) and associated tools. This article extends Mark Minasi's DNS introduction that appeared in the January issue.

The DNS, of course, is the distributed database on the Internet that maps host names to IP addresses. In addition, the DNS provides information about a domain's mail and name servers. But before we jump ahead of ourselves, let's review how one obtains an IP network number (NET_ID) and a domain name.

Historically on the Internet, names and addresses were doled out by the Internet Assigned Number Authority (IANA, http://www.iana.org). In 1993, the National Science Foundation (NSF) awarded a 5-year contract to Network Solutions, Inc. (NSI, http://www.networksolutions.com) to operate the name registration service of the then-new Internet Network Information Center (InterNIC, http://www.internic.net). The InterNIC, at the time, became the place to go to get a domain name in the .com, .org, or .net name space, as well as a NET_ID. For all practical purposes, you owned your IP address and could "take it with you" if you changed ISPs. The process today has changed significantly in two vital aspects.

First, let's deal with addresses themselves. In the western hemisphere and some parts of the African continent, the IP number authority is the American Registry of Internet Numbers (ARIN, http://www.arin.net); InterNIC has not assigned IP addresses since about 1997. To keep the size of Internet routing tables manageable, the unused address space several years ago was organized into Classless Interdomain Routing (CIDR) address blocks which are, in turn, assigned to ISPs or other regional number authorities, such as RIPE (http://www.ripe.net) in Europe and the Asia-Pacific NIC (APNIC, http://www.apnic.net). If you're in the U.S., you need to obtain an IP NET_ID address from ARIN when you connect to the Internet, usually in coordination with your ISP.

Because of the rapid exhaustion of addresses, it is very difficult today to get a full Class C address (although less than 50% of all possible Class C addresses have been allocated). ISPs and ARIN actually want to distribute as small an address block as possible and will assign NET_IDs with as few as 8 host addresses to a customer. They do this using variable-length subnet masks (VLSMs), a way of implementing classless addressing. A full description of VLSMs is beyond the scope of this article, the sidebar provides the motivation for using them and an example.

But how can a company with several hundred systems operate with just a small handful of IP addresses? The answer is Network Address Translation (NAT) and Request for Comments (RFC) 1918 private addresses. A company may have a large number of users but generally has only a few servers that require publicly visible IP addresses. One increasingly common solution is that organizations are using private IP addressing internally and public servers are also assigned a public IP address; NAT statically maps the server's public address to an internal private address. When a client system communicates with the Internet, the client is dynamically and temporarily assigned a public address. Port Address Translation (PAT), also called NAT overload, is employed if more clients need addresses than there are available public addresses. NAT and PAT address management occurs transparently at the router or NAT server, so users never see this.

If you'd like to know more about the current address assignments, visit John Crossley's IP Network Index (http://www.ipindex.net/), an index relating IP Class A, B, and C network numbers to network names.

The second big change is with respect to domain name registration. The NSF's contract with NSI expired in April 1998. Unfortunately, it seems to have never occurred to anyone what to do after that date so NSI's contract has been extended several times, now through at least September 2000. In 1998, the Internet Corporation for Assigned Names and Numbers (ICANN, http://www.icann.org) was formed to create a fair yet efficient domain name registration arrangement. There are many factors behind the formation of ICANN and a good description of the history and evolution of ICANN can be found at the National Telecommunications and Information Administration (NTIA) Web site (http://www.ntia.doc.gov/ntiahome/domainname/). The bottom line is that while NSI remains the sole administrator of names in the .com, .org, and .net name space, there are now many companies that can register names in that space, such as America Online (http://www.aol.com), Melbourne IT (http://www.ina.com.au), and register.com (http://www.register.com). A list of all accredited name registrars can be found at the ICANN Web site at http://www.icann.org/registrars/accredited-list.html.

The DNS is a distributed data base containing host, mail server, name server, and other domain information. A primary name server and at least one secondary name server must be maintained for every Internet domain. When a client system on the Internet needs to find the IP address of a server (e.g., a reader of this article surfing to www.winntmag.com or sending e-mail to gkessler@symquest.com), the client sends a DNS query to its local name server. If the local name server doesn't have the necessary address information for the target server, the local name server sends a query to one of 13 well-known root name servers on the Internet to determine the target domain's name servers. The query is then forwarded to one of the target domain's name servers for final resolution.

Many ISPs provide primary and secondary DNS service; others only provide secondary DNS service and require that the customer host the primary name server. Examining the DNS file structure, then, will remove a lot of mystery from the name lookup process and provide some practical detail that you may need in the future.

DNS information is, classically, kept in simple text files called zone files, each comprising different types of information called resource records (RRs). The most common RRs are:

• Start of Authority (SOA): Indicates the primary name server for a given domain plus a few additional administrative items.
• Address (A): Supplies the IP address for a given host name.
• Canonical Name (CNAME): Provides alias host names so that more than a single host name can be associated with a given IP address.
• Pointer (PTR): Associates a host name with a given IP address, used for reverse name lookups.
• Mail Exchange (MX): Defines the mail system(s) for a given domain.
• Name Server (NS): Defines the name server(s) for a given domain.

The list below shows a sample zone file for the fictitious example.com domain, mapping host names to IP addresses. In this example, the domain hosts Web, FTP, e-mail, 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; it is used here for sample purposes only:

 example.com.   IN SOA  dns.example.com.  dnsowner.example.com. 
                     (19991005   ; serial # (date format)
                         10800   ; refresh (3 hours)
                          3600   ; retry (1 hour)
                        604800   ; expire (1 week)
                         86400)  ; TTL (1 day)
 example.com.   IN NS   dns.example.com.
                IN NS   ns1.ispexample.net.
 example.com.   IN MX   20  mail.example.com.
                IN MX   40  mail.ispexample.com.
 dns.example.com.        IN A      192.168.210.2
 mail.example.com.       IN A      192.168.210.4
 www.example.com.        IN A      192.168.210.5
 ftp.example.com.        IN CNAME  www.example.com.

So what do all of these records indicate?

• The SOA record includes the name of the primary DNS server for this domain and the e-mail address associated with this domain's naming administrator; note that the e-mail address of the DNS administrator is listed with a "." in lieu of the "@" because the at-sign has special meaning in DNS files. This resource record also contains five other parameters: a serial number indicating the version of this information (this is how a secondary server knows that there is new information to download), a refresh value that tells the secondary name server(s) how often to check for updated information, a retry value that tells the secondary server(s) how often to reattempt connections to the primary, an expire value that tells the secondary server(s) when the information in their databases is so old as to be unreliable, and a time-to-live (TTL) value that tells a requester how long the information can safely be cached.

• The NS records contain the name of the name servers for this domain; note that the first one listed is the primary because it is the one named in the SOA record.

• The MX record contains the name of the e-mail server for this domain. The number before the address is the preference value and is most useful when the domain has two or more e-mail servers. When a remote user sends mail to user@example.com, the remote mail system looks up the MX record for the example.com domain. The remote mailer will then attempt to establish a Simple Mail Transfer Protocol (SMTP) connection with the mail server with the lowest preference value. In this way, an organization can specify multiple mail servers with the same preference level for load balancing and/or servers with different preference levels to provide a backup.

• The A records contain the IP address to be associated with each of the listed host names that are 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 given two different names that map to the same IP address. There is a good reason to do this; namely, the FTP service, for example, may be moved to another system in the future and the scheme shown here ensures that external users never need to know.

There is another important zone file associated with each domain and that is the reverse lookup file, which maps an IP address to a host name. The zone file for the fictitious 192.168.210.0 address space (assuming that there is a single owner of this entire Class C address) might look like the following:

 210.168.192.in-addr.arpa. IN SOA dns.example.com. dnsowner.example.com. 
                               (19990930   ; serial # (date format)
                                   10800   ; refresh (3 hours)
                                    3600   ; retry (1 hour)
                                  604800   ; expire (1 week)
                                   86400)  ; minimum TTL (1 day)
 210.168.192.in-addr.arpa.  IN NS   dns.example.com.
                            IN NS   ns1.ispexample.net.
 2.210.168.192.in-addr.arpa.    IN PTR    dns.example.com.
 4.210.168.192.in-addr.arpa.    IN PTR    mail.example.com.
 5.210.168.192.in-addr.arpa.    IN PTR    www.example.com.

The only new resource records shown here are the PTR records, which associate an IP address with a host name.

DNS server software may be found by a variety of names depending on the operating system; Windows NT usually refers simply to DNS while UNIX will have named (name daemon) or BIND (Berkeley Internet Name Daemon); BIND is the most common. Although the different DNS software packages implement some things differently, it is useful to understand the RRs and file formats to see how the domain name information is laid out.

Products are available from Microsoft and a number of third-parties that allow you to provide a DNS service on a Windows NT Server. Some of the product below support dynamic DNS (DDNS), a capability to dynamically update the DNS entries in those environments where host IP addresses are assigned dynamically. All take advantage of NT's GUI interface:

• BIND for NT is a freeware port of BIND to Windows NT (and several other operating systems) from Software.com (http://www.software.com/products/bindnt.html).
• DNS Pro is a BIND-compatible DNS from FBLI Software (http://www.fbli.com/english/dnspro.htm).
• Meta DNS is another port of BIND, from Check Point Software Technologies (http://www.metainfo.com/products/metadns.cfm)
• Microsoft DNS Service comes standard with Windows NT and is a Microsoft-developed version of DNS software rather than a port of BIND (http://www.microsoft.com/NTServer/nts/deployment/planguide/dnswp.asp).
• NetID 4.1 DNS Server is an IP address management tool from Nortel that includes support for DNS and dynamic DNS (www.nortelnetworks.com/link/netid_4.1). NetID 1500 DNS Server provides similar functionality as a part of Nortel Networks Adaptive Networking IP Services (www.nortelnetworks.com/link/netid_1500).
• QIP Enterprise 5.0 is a platform to manage IP services across enterprise-wide networks from Lucent Technologies. QIP includes a dynamic DNS server that is a port of BIND (http://www.lucent.com/ins/products/qip_c.html).

• Shadow IPmanager for Windows is the part of Network TeleSystems' remote management suite that manages DNS and dynamic DNS databases (http://www.networktelesystems.com/products/remotemgmt.html).