DNS Basics

This section introduces the basic DNS concepts. It assumes that you have some familiarity with network administration, particularly TCP/IP, and some exposure to other name services, such as NIS+ and NIS.

Name-to-Address Resolution

Though it supports the complex, world-wide hierarchy of computers on the Internet, the basic function of DNS is actually very simple: providing name-to-address resolution for TCP/IP-based networks. Name-to-address resolution, also referred to as "mapping," is the process of finding the IP address of a computer in a database by using its host name as an index.

Name-to-address mapping occurs when a program running on your local machine needs to contact a remote computer. The program most likely will know the host name of the remote computer but may not know how to locate it, particularly if the remote machine is in another company, miles from your site. To get the remote machine's address, the program requests assistance from the DNS software running on your local machine, which is considered a DNS client.

Your machine sends a request to a DNS name server, which maintains the distributed DNS database. The files in the DNS database bear little resemblance to the NIS+ Host Table or even the local /etc/inet/hosts file, though they maintain similar information: the host names, IP addresses, and other information about a particular group of computers. The name server uses the host name your machine sent as part of its request to find or "resolve" the IP address of the remote machine. It then returns this IP address to your local machine IF the host name is in its DNS database.

Figure 10-1 shows name-to-address mapping as it occurs between a DNS client and a name server, probably on the client's local network.

Figure 10-1

If the host name is not in that name server's DNS database, this indicates that the machine is outside of its authority, or, to use DNS terminology, outside the local administrative domain. Thus, each name server is spoken of as being "authoritative" for its local administrative domain.

Fortunately, the local name server maintains a list of host names and IP addresses of root domain name servers, to which it will forward the request from your machine. These root name servers are authoritative for huge organizational domains, as explained fully in "DNS Hierarchy and the Internet" on page 158. These hierarchies resemble UNIX file systems, in that they are organized into an upside-down tree structure.

Each root name server maintains the host names and IP address of top level domain name servers for a company, a university, or other large organizations. The root name server sends your request to the top-level name servers that it knows about. If one of these servers has the IP address for the host you requested, it will return the information to your machine. If the top-level servers do not know about the host you requested, they pass the request to second-level name servers for which they maintain information. Your request is then passed on down through the vast organizational tree. Eventually, a name server that has information about your requested host in its database will return the IP address back to your machine.

Figure 10-2 shows name-to-address resolution outside the local domain.

.

Figure 10-2

DNS Administrative Domains

From a DNS perspective, an administrative domain is a group of machines that are administered as a unit. Information about this domain is maintained by at least two name servers; they are "authoritative" for the domain. The DNS domain is a purely logical grouping of machines. It could correspond to a physical grouping of machines, such as all machines attached to the Ethernet in

a small business. But a local DNS domain just as likely could include all machines on a vast university internetwork that belong to the computer science department or to university administration.

For example, suppose the Ajax company has two sites, one in San Francisco and one in Seattle. The Retail.Sales.Ajax.com. domain might be in Seattle and the Wholesale.Sales.Ajax.com. domain might be in San Francisco. One part of the Sales.Ajax.com. domain would be in one city, the other part in the second city.

Each administrative domain must have its own unique subdomain name. Moreover, if you want your network to participate in the Internet, the network must be part of a registered administrative domain. The section "Joining the Internet" on page 160 has full details about domain names and domain registration.

in.named and DNS Name Servers

As mentioned previously, name servers in an administrative domain maintain the DNS database. They also run the in.named daemon, which implements DNS services, most significantly, name-to-address mapping. in.named is a standard TCP/IP program and included with the Solaris 2.5 operating environment.

---

Note - The in.named daemon is also called the Berkeley Internet Name Domain service, or BIND, because it was developed at the University of California at Berkeley.

---

There are three types of DNS name servers:

• Primary server
• Secondary server
• Cache-only server

Each domain must have one primary server and at least one secondary server to provide backup. "Administering DNS" on page 162 explains primary and secondary servers in detail.

DNS Clients and the Resolver

To be a DNS client, a machine must run the resolver. The resolver is neither a daemon nor a single program; rather, it is a set of library routines used by applications that need to know machine names. The resolver's function is to resolve users' queries. To do that, it queries a name server, which then returns either the requested information or a referral to another server. Once the resolver is configured, a machine can request DNS service from a name server.

When the /etc/nsswitch.conf file specifies dns first, the resolver libraries are automatically used.

There are two kinds of DNS clients:

• Client-only
• Client-server

A client-only DNS client does not run in.named; instead, it consults the resolver. The resolver provides a list of name servers for the domain, to which queries are then directed. A client-server client uses the services provided by in.named to resolve a user's queries.

The Solaris 2.5 operating environment includes the library routines making up the resolver by default. Chapter 11, "Setting Up DNS Clients," contains instructions for setting up a host as a DNS client.

Introducing the DNS Namespace

The entire collection of DNS administrative domains throughout the world are organized in a hierarchy called the DNS namespace. This section shows how the namespace organization affects both local domains and the Internet.

DNS Namespace Hierarchy

Like NIS+ domains (and the UNIX file system), DNS domains are organized as a set of descending branches like the roots of a tree. Each branch is a domain, each subbranch is subdomain. The terms domain and subdomain are relative. A given domain is a subdomain relative to those domains above it in the hierarchy, and a parent domain to the subdomains below it.

Figure 10-3

For example, in Figure 10-3, com is a parent domain to the Acme, Ajax, and AAA domains. Or you could just as easily say that those are subdomains relative to the com domain. In its turn, the Ajax domain is a parent to four subdomains (Sales, Eng, QA, and Corp).

A domain contains one parent (or top) domain plus the associated subdomains if any. Domains are named up the tree starting with the lowest (deepest) subdomain and ending with the root domain.

DNS Hierarchy in a Local Domain

If your company is large enough, it may support a number of domains, organized into a local namespace. Figure 10-4 shows a domain hierarchy that might be in place in a single company. The top-level, or "root" domain for the organization is ajax.com, which has three sub-domains, sales.ajax.com, test.ajax.com, and eng.ajax.com.

Figure 10-4

DNS clients request service only from the servers that support their domain. If the domain's server does not have the information the client needs, it forwards the request to its parent server, which is the server in the next-higher domain in the hierarchy. If the request reaches the top-level server, the top-level server determines whether the domain is valid. If it is not valid, the server returns a "not found" type message to the client. If the domain is valid, the server routes the request down to the server that supports that domain.

DNS Hierarchy and the Internet

The domain hierarchy shown in Figure 10-4 on page 158 is, conceptually, a "leaf" of the huge DNS namespace supported on the Internet.

The DNS namespace for the Internet is organized hierarchically, as shown in Figure 10-5. It consists of the root directory, represented as a dot (.) and two main domain hierarchies, one organizational and one geographical. Note that the com domain introduced inFigure 10-3 on page 157 is one of a number of top-level organizational domains in existence on the Internet.

Figure 10-5

The organizational hierarchy divides its namespace into the top-level domains listed in Table 10-1.

Table 10-1

Domain	Purpose
com	Commercial organizations
edu	Educational institutions
gov	Government institutions
mil	Military groups
net	Major network support centers
org	Nonprofit organizations and others
int	International organizations

The geographic hierarchy assigns each country in the world a two- or three-digit identifier and provides official names for the geographic regions within each country. For example, domains in Britain are subdomains of the uk top-level domain, Japanese domains are subdomains of jp, and so on.

Joining the Internet

The Internet root domain, top-level organizational domains, and top-level geographic domains are maintained by the Internet governing bodies. Organizations with networks of any size can join the Internet by applying for membership in either the organizational or the geographical hierarchy.

Every DNS administrative domain must have a domain name. If your site wants to use DNS for name service without joining the Internet, you can use any name your organization wants for its administrative domains and subdomains, if applicable. However, if your site ever plans to join the Internet, it must register its domain name with the Internet governing bodies.

To join the Internet, you or another network administrator has to:

• Register your network and obtain a network number from the Internet governing bodies.
• Register your DNS domain with the Internet governing bodies.

There are two ways to accomplish this. You can directly contact the InterNIC, currently the organization that handles network address and domain registration. See TCP/IP and Data Communications Administration Guide for addresses and instructions.

But today, the more common approach is to employ an Internet Service Provider (ISP) to assist you. ISPs can help set up your physical Internet connection, register your network, and assist you with DNS issues. Some ISPs may provide secondary DNS name servers to back up the primary server at your site. If your network is small, some ISPs may include it in a local domain that they administer. Contact the various regional and national ISPs listed in your phone book and computer trade magazines to find the Internet Service Provider that best supports your site's needs.

Domain Names

Domain names indicate a domain's position in the overall DNS namespace, much as path names indicate a file's position in the UNIX file system. After your local domain is registered, its name is prepended to the name of the Internet hierarchy to which it belongs. For example, the ajax domain shown in Figure 10-4 on page 158 has been registered as part of the Internet com hierarchy. Therefore, its Internet domain name becomes ajax.com.

Figure 10-6 shows the position of the ajax.com domain in the DNS namespace on the Internet.

Figure 10-6

The ajax.com subdomains now have the following names.

  sales.ajax.com
  test.ajax.com
  eng.ajax.com

DNS does not require domain names to be capitalized, though they may be. Here are some examples of machines and domain names:

Boss.ajax.com
quota.Sales.ajax.com

The Internet regulates administration of its domains by granting each domain authority over the names of its hosts and by expecting each domain to delegate authority to the levels below it. Thus, the com domain has authority over the names of the hosts in its domain. It also authorizes the formation of the Wiz.com domain and delegates authority over the names in that domain. The Wiz.com domain, in turn, assigns names to the hosts in its domain and approves the formation of the Sales.Wiz.com, Test.Wiz.com, and Eng.Wiz.com domains.

Fully-Qualified Domain Names A domain name is said to be fully-qualified when it includes the names of every DNS domain from the local domain on up to ".", the DNS root domain. Conceptually, the fully-qualified domain name indicates the path to the root, as does the absolute path name of a UNIX file. However, fully-qualified domain names are read from lowest, on the left, to highest, on the right. Therefore, a fully-qualified domain name has the syntax:

The fully qualified domain names for the ajax domain and its subdomains are:

ajax.com.
test.ajax.com.
eng.ajax.com.

Note the dot at the furthest right position of the name.

Administering DNS

DNS service for a domain is managed on the set of name servers first introduced on page 155. Name servers can manage a single domain, or multiple domains, or domains and some or all of their corresponding subdomains. The part of the namespace that a given name server controls is called a zone; thus, the name server is said to be authoritative for the zone. If you are responsible for a particular name server, you may be given the title zone administrator.

Zone s

The data in a name server's database are called zone files. One type of zone file stores IP addresses and host names. When someone attempts a remote procedure such as ftp or telnet, the file provides the name of the remote host. DNS performs name-to-address mapping, by look up the host name in the zone file and converting it into its IP address.

Figure 10-7

For example, the Ajax domain shown in Figure 10-7 contains a top domain (Ajax), four subdomains, and five sub-subdomains. It is divided into four zones shown by the thick lines. Thus, the Ajax name server administers a zone composed of the Ajax, Sales, Retail, and Wholesale domains. The R&D and QA domains are zones unto themselves served by their own name servers, and the Corp name server manages a zone composed of the Corp, Actg, Finance, and Mktg domains.

Reverse Mapping

The DNS database also include zone files that use the IP address as a key to find the host name of the machine, enabling IP address to host name resolution. This process is called reverse resolution or commonly, reverse mapping. Reverse mapping is used primarily to verify the identity of the machine that sent a message or to authorize remote operations on a local host.

The in.addr.arpa Domain

The in.addr.arpa domain is a conceptual part of the DNS namespace that uses IP addresses for its leaves, rather than domain names. It is the part of your zone that enables address to name mapping.

Just as DNS domain names are read with the lowest level subdomain occupying the furthest left position and the root at the far right, in.addr.arpa domain IP addresses are read from lowest level to the root. Thus, the IP addresses are read backward. For example, suppose a host has the IP address 192.200.21.165. In the in.addr.arpa zone files, its address is listed as 165.21.200.192.in.addr.arpa. with the dot at the end indicating the root of the in.addr.arpa domain.

Master Servers

The master name servers maintain all the data corresponding to the zone, making them the authority for that zone. These are commonly called authoritative name servers. The data corresponding to any given zone should be available on at least two authoritative servers. You should designate one name server as the primary master server and at least one as a secondary master server, to act as a backup if the primary is unavailable or overloaded.

Primary Name Server

The primary master server is the name server where you make changes for the zone. This server loads the master copy of its data from disk when it starts in.named. The primary server may also delegate authority to other servers in its zone as well as to servers outside its zone.

Secondary Name Server

The secondary master server maintains a copy of the data for the zone. The primary server sends its data and delegates its authority to the secondary server. When the secondary server boots in.named, it requests all the data for the given zone from the primary. The secondary server then periodically checks with the primary to see if it needs to update its database. The process of sending the most recent zone database from the primary to the secondary is called a zone transfer.

A server may function as a master for multiple zones: as a primary for some zones, and as a secondary for others.

Root Domain Name Server

The DNS name space must have a root domain name server. If your site is not connected to the Internet, you must set up a root domain for your organization and administer primary and secondary name servers for the root level of the local network.

Caching and Caching-Only Servers

All name servers are caching servers. This means that the name server caches received information until the data expires. The expiration process is regulated by the time-to-live field attached to the data when it is received from another server.

Additionally, you can set up a caching-only server that is not authoritative for any zone. This server handles queries and asks other name servers that have the authority for the information needed. But the caching-only server does not maintain any authoritative data itself.

How DNS Affects Mail Delivery

DNS provides two principal services, it performs name to address mapping (and also maps addresses to host names), as discussed in on page 152. It also helps mail delivery agents, such as sendmail and POP, deliver mail along the Internet.

To deliver mail across the Internet, DNS uses mail exchange records (MX records). Many organizations don't allow direct delivery of mail that comes across the Internet for hosts within the organization. Instead, they use a central mail host (or a set of mail hosts) to intercept incoming mail messages and route them to their recipients.

The mail exchange record identifies the mail host that services each machine in a domain. Therefore, a mail exchange record lists the DNS domain names of remote organizations and either the IP address or the host name of its corresponding mail host.

Table 10-2

DNS Domain	Mail Host
International.com.	129.44.1.1
sales.ajax.com.	SalesAjaxMailer
eng.ajax.com.	EngAjaxMailer
Fab.com.	FabMailer

When the mail agent receives a request to send mail to another domain, it parses the address of the recipient from right to left and looks for a match in the table.

If it receives a request to send mail to neverhome.sales.ajax.com, it first extracts the topmost label, com. It examines the mail exchange record to see if there is an entry for com. Since there is none, it continues parsing. It extracts the next label and looks for an entry for ajax.com. Since there is none, it continues looking. The next entry it looks for is sales.ajax.com. As you can see in Table 10-2, the mail host for that domain is SalesAjaxMailer. Because that is a host name, the mail agent asks DNS to resolve it. When DNS provides that mail host's IP address, the mail agent sends the message.

If, instead of the mail host name, the mail exchange record had specified an IP address, the mail agent would have sent the message directly to that address, since it would have needed no name resolution from DNS.