Before 1980, the ARPANET had only a few hundred networked computers. The computer name-to-address mapping was contained in a single file called Hosts.txt. This file was stored on the host computer of the Stanford Research Institute's Network Information Center (SRI-NIC) in Menlo Park, California. Other host computers on the ARPANET copied the Hosts.txt file from the SRI-NIC to their sites as needed.

Initially, this scheme worked well because the Hosts.txt list needed to be updated only one or two times a week. However, in a few years, problems arose due to the ever-increasing size of the ARPANET. The problems included the following:

These and other problems led the governing body of the ARPANET to find a solution to the mechanism surrounding the Hosts.txt file. The decision led to the creation of the domain name system (DNS), which is a distributed database using a hierarchical name structure (hierarchical name space).

The domain name system is described in Request for Comments (RFCs) 1034 and 1035.

The domain name system is a hierarchical client/server-based distributed database management system. DNS maps to the Application layer and uses User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) as the underlying protocols.

The purpose of the DNS database is to translate computer names into Internet Protocol (IP) addresses. In the DNS, the clients are called resolvers and the servers are called name servers.

The domain name system is analogous to a telephone book. The user looks up the name of the person or organization that he wants to contact and cross-references the name to a telephone number. Similarly, a host computer contacts the name of a computer and a domain name server cross-references the name to an IP address.

Resolvers first send UDP queries to servers for increased performance and resort to TCP only if truncation of the returned data occurs.

The function of the resolvers is to pass name requests between applications and name servers. The name request contains a query. For example, the query might ask for the IP address of a World Wide Web (WWW) site. The resolver is often built into the application or is running on the host computer as a library routine.

Name servers take name requests from resolvers and resolve computer (or domain) names to IP addresses. If the name server is not able to resolve the request, it may forward the request to a name server that can resolve it. The name servers are grouped into different levels that are called domains.

Domains define different levels of authority in a hierarchical structure. The top of the hierarchy is called the root domain. The root domain uses a null label, but references to the root domain can be expressed by a period (.).

The following are the top-level domains, at the present time:

Top-level domains can contain second-level domains and hosts.

Host names inside domains are added to the beginning of the domain name and are often referred to by their fully qualified domain name (FQDN). For example, a host named fileserver in the microsoft.com domain would have the fully qualified domain name of fileserver.microsoft.com.

A zone of authority is the portion of the domain name space for which a particular name server is responsible. The name server stores all address mappings for the domain name space within the zone and answers client queries for those names.

The name server's zone of authority encompasses at least one domain. This domain is referred to as the zone's root domain. The zone of authority may also include subdomains of the zone's root domain. However, a zone does not necessarily contain all the subdomains under the zone's root domain.

In the preceding illustration, Microsoft (microsoft.com) is a domain, but the entire domain is not controlled by one zone file. Part of the domain is located in a separate zone file for dev.microsoft.com. Breaking up domains across multiple zone files may be needed for distributing management of the domain to different groups, or for data replication efficiency.

A single DNS server can be configured to manage one or multiple zone files. Each zone is anchored at a specific domain node called the zone's root domain.

DNS servers can store and maintain their database of names in several different ways. Each of the following roles describes a different way a DNS name server can be configured to store its zone data.

The primary name server obtains zone data from local files. Changes to a zone, such as adding domains or hosts, are done at the primary name server level.

A secondary name server obtains the data for its zones from another name server across the network that has authority for that zone. Obtaining this zone information across the network is referred to as a zone transfer.

There are three reasons to have secondary name servers:

Because information for each zone is stored in separate files, this primary or secondary designation is defined at a zone level. In other words, a particular name server may be a primary name server for certain zones and a secondary name server for other zones.

When you define a zone on a name server as a secondary zone, you must designate another name server from which to obtain the zone information. The source of zone information for a secondary name server in a DNS hierarchy is referred to as a master name server. A master name server can be either a primary or secondary name server for the requested zone. When a secondary name server starts up, it contacts its master name server and initiates a zone transfer with that server.

Although all DNS name servers cache queries that they have resolved, caching-only servers are DNS name servers that only perform queries, cache the answers, and return the results. In other words, they are not authoritative for any domains (no zone data is kept locally) and only contain information that they have cached while resolving queries.

When trying to determine when to use such a server, keep in mind that when the server is initially started it has no cached information and must build up this information over time as it services requests. Much less traffic is sent across the slow link because the server is not doing a zone transfer. This is important if you are dealing with a slow link between sites.

There are three types of queries that a client (resolver) can make to a DNS server: recursive, iterative and inverse.

In a recursive query, the queried name server is petitioned to respond with the requested data, or with an error stating that data of the requested type does not exist or that the domain name specified does not exist. The name server cannot refer the request to a different name server.

In an iterative query, the queried name server gives the best answer it currently has back to the requester. This answer may be the resolved name or a referral to another name server that may be able to answer the client's original request.

The preceding illustration demonstrates an example of both recursive and iterative queries. A client within Microsoft Corporation is querying its DNS server for the IP address for "www.whitehouse.gov."

In an inverse query, the resolver sends a request to a name server to resolve the host name associated with a known IP address. There is no correlation between host names and IP addresses in the DNS name space. Therefore, only a thorough search of all domains guarantees a correct answer.

To prevent an exhaustive search of all domains for an inverse query, a special domain called "in-addr.arpa" was created. Nodes in the in-addr.arpa domain are named after the numbers in the dotted decimal representation of IP addresses. Because IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in-addr.arpa domain. With this arrangement, administration of lower limbs of the in-addr.arpa domain can be delegated to organizations as they are assigned their class A, B, or C IP addresses.

Once the in-addr.arpa domain is built, special resource records called pointer (PTR) records are added to associate the IP addresses and the corresponding host name. For example, to find a host name for the IP address 157.55.200.51, the resolver queries the DNS server for a pointer record for 51.200.55.157.in-addr.arpa. The pointer record found contains the host name and corresponding IP address, 157.55.200.51 This information is sent back to the resolver. Part of the administration of a DNS name server is ensuring that pointer records are created for hosts.

When a name server is processing a recursive query, it may be required to send out several queries to find the answer. The name server caches all of the information that it receives during this process for a time that is specified in the returned data. This amount of time is referred to as the Time To Live (TTL). The name server administrator of the zone that contains the data decides on the TTL for the data. Smaller TTL values will help ensure that data about the domain is more consistent across the network if this data changes often. However, this will also increase the load on name servers.

Once data is cached by a DNS server, it must start decreasing the TTL from its original value so that it will know when to flush the data from its cache. If a query comes in that can be satisfied by this cached data, the TTL that is returned with the data is the current amount of time left before the data is flushed from the DNS server cache. Client resolvers also have data caches and honor the TTL value so that they know when to expire the data.

The following table contains the names of the files that are associated with a typical DNS server.

Reverse lookup file (z.y.w.x.in-addr.arpa) The reverse lookup file maps IP addresses to host names. For example, if your network is the class C network address 192.138.154.0, then this file will be called 154.138.192.in-addr.arpa.

Cache file (cache.dns) The cache file is essentially the same on all name servers and must be present. This file contains the names and addresses for the name servers that maintain the root domain.

Boot file The boot file is typically used by a DNS server for start-up configuration. This file contains host information needed to resolve names outside authoritative domains.

The database file stores resource records for a domain. There are several types of resource records defined in DNS. RFC 1034 defines SOA, A, NS, PTR, CNAME, MX, and HINFO record types. Microsoft has added the WINS and WINS-R Microsoft-specific record types.

The first record in any database file must be the Start of Authority record (SOA). The SOA defines the general parameters for the DNS zone. The following is an example of a Start of Authority record:

@ IN SOA nameserver1.microsoft.com. glennwo.microsoft.com. (

1 ; serial number

10800 ; refresh [3 hours]

3600 ; retry [1 hour]

604800 ; expire [7 days]

86400 ) ; time to live [1 day]

The following rules apply to all SOA records:

The Name Server record (NS) lists the additional name servers. A database file may contain more than one name server record. The following is an example of a name server record:

@ IN NS nameserver2.microsoft.com

A Host record (A) statically associates a host name to its IP address. Host records comprise most of the database file and list all hosts within the zone. The following are examples of host records:

rhino IN A 157.55.200.143

localhost IN A 127.0.0.1

A Canonical Name record (CNAME) enables you to associate more than one host name with an IP address. This is sometimes referred to as aliasing. The following is an example of a CNAME record:

FileServer1 CNAME rhino

www CNAME rhino

ftp CNAME rhino

Database record types are defined in RFCs 1034, 1035, and 1183.

The reverse lookup file allows a resolver to provide an IP address and request a matching host name. A reverse lookup file is named similarly to a zone file according to the in-addr.arpa zone for which it is providing reverse lookups. For example, to provide reverse lookups for the IP network 157.57.28.0, a reverse lookup file is created with a file name of 57.157.in-addr.arpa. This file contains SOA and name server records similar to other DNS database zone files, as well as pointer records.

This DNS reverse-lookup capability is important because some applications provide the capabilities to implement security based on the connecting host names. For instance, if a client tries to link to a network file system (NFS) volume with this security arrangement, the NFS server would contact the DNS server and do a reverse name lookup on the client's IP address. If the host name returned by the DNS server is not in the access list for the NFS volume or if the host name was not found by DNS, then the NFS request would be denied.

Pointer (PTR) records provide an address-to-name mapping within a reverse lookup zone. IP numbers are written in backward order and "in-addr.arpa" is appended to the end to create this pointer record. As an example, looking up the name for "157.55.200.51" requires a pointer query for the name "51.200.55.157.in-addr.arpa."

51.200.55.157.in-addr.arpa. IN PTR mailserver1.microsoft.com.

The cache file contains host information that is needed to resolve names outside of authoritative domains. It contains names and addresses of root name servers. The default file provided with the Windows NT version 4.0 DNS Server has the records for all of the root servers on the Internet. For installations not connected to the Internet, the file should be replaced to contain the name server's authoritative domains for the root of the private network.

For a current Internet cache file see ftp://rs.internic.net/domain/named.cache.

The boot file is not defined in an RFC and is not needed in order to be RFC compliant. This file is a part of the Berkeley Internet Name Daemon (BIND)–specific implementation of DNS. The Windows NT version 4.0 DNS Server can be configured to use a boot file, if administration is to be done through changes to the text files, rather than by using DNS Manager.

This file controls the start-up behavior of the DNS server. Commands must start at the beginning of a line and no spaces may precede commands. Recognized commands are: directory, cache, primary, and secondary.

The syntax for this file is as shown in the following table.

Directory command Specifies a directory where other files referred to in the boot file can be found.

Cache command Specifies a file used to help the DNS service contact name servers for the root domain. This command and the file it refers to must be present. A cache file suitable for use on the Internet is provided with Windows NT 4.0.

Primary command Specifies a domain for which this name server is authoritative and a database file that contains the resource records for that domain (that is, zone file). Multiple primary command records can exist in the boot file.

Secondary command Specifies a domain for which this name server is authoritative and a list of master server IP addresses from which to attempt to download the zone information, rather than reading it from a file. It also defines the name of the local file for caching this zone. Multiple secondary command records could exist in the boot file.

The following table contains examples of the commands in a boot file.

Rather than maintain a DNS server, an organization with a small network may find it simpler and more efficient to have DNS clients query a DNS name server maintained by an Internet Service Provider (ISP). Most ISPs will maintain domain information for a fee. Organizations that want to control their domain or cut the costs of using an ISP should maintain their own DNS servers.

If an organization, regardless of size, wants to connect to the Internet, the registration organization InterNIC must be informed of the domain name of the organization and the IP addresses of at least two DNS servers that service the domain. An organization could set up DNS servers within itself independent of the Internet.

For reliability and redundancy, Microsoft recommends that at least two DNS servers be configured per domain—a primary and a secondary name server. The primary name server maintains the database of information, which is replicated to the secondary name server. This replication allows name queries to be serviced even if one of the name servers is unavailable. The replication scheduled can be configured depending on how often names change in the domain. Replication should be frequent enough so that changes are known to both servers. However, excessive replication can tie up the network and name servers unnecessarily.

Once you have your DNS server or servers configured and installed, you need to register with the DNS server that is above you in the hierarchical naming structure of DNS. The parent system needs the name and addresses of your name servers and may require other information, such as the date that the domain becomes available and the names and addresses of contact people.

If you are registering with a parent below the second-level domain, check with the administrator of that system to determine the information you need to supply.

If you are registering at the subdomain or higher, visit InterNIC's online registration services at http://internic.net. If you have any questions, call their registration Help line at (703) 742-477.

Integration of DNS and WINS automatically happens when DNS is configured to resolve names that are not listed in the DNS table.

Although DNS might seem similar to WINS, there are two major differences, as summarized in the following table.

Resolves Internet names to IP addresses. Resolves NetBIOS names to IP addresses.

Static database of computer name to IP address mappings. It must be manually updated. Dynamic database of NetBIOS names and IP addresses. It is dynamically updated.

Used for clients running Microsoft operating systems and clients and hosts that are not running Microsoft operating systems, such as UNIX-based computers and mainframes running TCP/IP. Used for name resolution for clients running Microsoft operating system only, including Windows NT Server, Windows NT Workstation, and Windows 95.

The Windows NT DNS Server service can be configured to use WINS for host name resolution through DNS Manager. Select the zone and view its properties. On the WINS Lookup tab, click Use WINS Resolution, and then specify WINS servers' addresses. This integration creates a form of dynamic DNS Server service that takes advantage of the features of both DNS and WINS. This integration allows DNS to query WINS for name resolution of the lower levels of the DNS tree. This final WINS resolution is transparent to the client, which sees the DNS name server as handling the entire process.