Uthe Hosts.Txt File Became Too Large

1

APPENDIX C

DNS

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:

uThe Hosts.txt file became too large.

uThe file needed to be updated more than once a day.

uBecause all network traffic had to be routed through SRI-NIC, maintaining Hosts.txt became a restriction point for the entire network.

uNetwork traffic on the SRI-NIC host became almost unmanageable.

uHosts.txt uses a flat name structure (name space). This required every computer name to be unique across the whole network.

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).

Note

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

How DNS Works

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.

Resolvers

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

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.

Domain Name Space

Root-Level 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 (.).

Top-Level Domains

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

ucom—Commercial organizations

uedu—Educational institutions and universities

uorg—Not-for-profit organizations

unet—Networks (the backbone of the Internet)

ugov—Non-military government organizations

umil—Military government organizations

unum—Phone numbers

uarpa—Reverse DNS

uxx—Two-letter country code

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

Second-Level Domains

Second-level domains can contain both hosts and other domains called subdomains. For example, the Microsoft® domain, microsoft.com, can contain computers such as ftp.microsoft.com and subdomains such as dev.microsoft.com. The subdomain dev.microsoft.com can contain hosts such as ntserver.dev.microsoft.com.

Host Names

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.

Zones of Authority

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.

Name Server Roles

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.

Primary Name Servers

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.

Secondary Name Servers

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:

uRedundancy. You need at least one primary and one secondary name server for each zone. The computers should be as independent as possible.

uFaster Access for Remote locations. If you have a number of clients in remote locations, having secondary name servers (or other primary name servers for subdomains) prevents these clients from communicating across slow links for name resolution.

uReduction of load. Secondary name servers reduce the load on the primary server.

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.

Master Name Servers

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.

Caching-Only Servers

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.

Name Resolution

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

Recursive Queries

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.

Iterative Queries

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 “

1.The resolver sends a recursive DNS query to its local DNS server asking for the IP address of “ The local name server is responsible for resolving the name and cannot refer the resolver to another name server.

2.The local name server checks its zones and finds no zones corresponding to the requested domain name. It then sends an iterative query for to a root name server.

3.The root name server has authority for the root domain and will reply with the IP address of a name server for the gov top-level domain.

4.The local name server sends an iterative query for “ to the gov name server.

5.The gov name server replies with the IP address of the name server servicing the whitehouse.gov domain.

6.The local name server sends an iterative query for “ to the whitehouse.gov name server.

7.The whitehouse.gov name server replies with the IP address corresponding to

8.The local name server sends the IP address of “ back to the original resolver.

Inverse Queries

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.

Caching and TTL

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.

Configuring the DNS Files

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

Name / Description
Database file
(zone.dns) / The database file stores resource records for a domain. For example, if your zone is “microsoft.com,” then this file will be called “microsoft.com.dns.” Microsoft WindowsNT® 4.0 supplies a sample database file called Place.dns as a template you can work with. This file should be edited and renamed before you use it on a production DNS server. It is generally a good idea to name this file the same as the zone it represents. This is the file that will be replicated between masters and secondaries.
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

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.

Start of Authority Record

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:

uThe at symbol (@) in a database file indicates “this server.”

uIN indicates an Internet record.

uAny host name not terminated with a period (.) will be appended with the root domain.

uThe @ symbol is replaced by a period (.) in the e-mail address of the administrator.

uParentheses ( () ) must enclose line breaks to span more than one line.

Name Server Record

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

Host Record

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:

rhinoIN A 157.55.200.143

localhostIN A 127.0.0.1

CNAME Record

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:

FileServer1CNAME rhino

wwwCNAME rhino

ftpCNAME rhino

Note

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

The Reverse Lookup File

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.