Chapter 3 Domain Name System (Overview)

This chapter describes the structure and provides an overview of the Domain Name System (DNS).

One of the most common and important uses of DNS is connecting your network to the global Internet. To connect to the Internet, your network IP address must be registered with whomever is administering your parent domain.

This chapter covers the following topics.

• DNS Basics

• Server Configuration and Data File Names

• Domain Names

• The resolv.conf File

• The named.conf File

• Zones

DNS Basics

The Domain Name System (DNS) is an application–layer protocol that is part of the standard TCP/IP protocol suite. This protocol implements the DNS naming service, which is the naming service used on the Internet.

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 naming services, such as NIS+ and NIS.

Refer to Chapter 4, Administering DNS (Tasks) for information regarding initial setup and configuration of DNS.

DNS, NIS+, NIS, and FNS provide similar functionality and sometimes use the same terms to define different entities. Thus, this chapter takes care to define terms like domain and name server according to their DNS functionality, a very different functionality than NIS+ and NIS domains and servers.

Name-to-Address Resolution

Though it supports the complex, worldwide 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 might 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 or ipnodes Table or even the local /etc/hosts or /etc/inet/ipnodes file, though they maintain similar information: the host names, the ipnode names, IPv4 and IPv6 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.

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

Figure 3–1 Name to Address Resolution

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

The following figure shows name-to-address resolution outside the local domain.

Figure 3–2 Name to Address Resolution for a Remote Host

DNS Administrative Domains

From a DNS perspective, an administrative domain is a group of machines which are administered as a unit. Information about this domain is maintained by at least two name servers, which are “authoritative” for the domain. The DNS domain is a logical grouping of machines. The domain groupings could correspond to a physical grouping of machines, such as all machines attached to the Ethernet in a small business. Similarly, a local DNS domain could include all machines on a vast university network 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 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. in.named is a public domain TCP/IP program and is included with the Solaris operating environment.

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

• Master server

• Slave server

• Stub server

Each domain must have one master server and should have at least one slave server to provide backup. Implementing DNS explains primary and secondary servers in detail.

Server Configuration and Data File Names

To function correctly, the in.named daemon requires a configuration file and four data files.

Configuration File

The master server configuration file is /etc/named.conf. The configuration file contains a list of domain names and the file names containing host information. See The named.conf File for additional information on the named.conf file.

Names of DNS Data Files

If you are internally consistent, you can name the zone data files anything you want. This flexibility might lead to some confusion when working at different sites or referring to different DNS manuals and books.

For example, the file names used in Sun manuals and at most many Solaris sites vary from those used in the book DNS and BIND published by O'Reilly & Associates and both of those nomenclatures have some differences from that used in the public-domain Name Server Operations Guide for BIND.

In addition, this manual and other DNS documentation use generic names that identify a file's main purpose, and specific example names for that file in code samples. For example, this manual uses the generic name hosts when describing the function and role of that file, and the example names db.doc and db.sales in code samples.

The required data files are the following.

• /var/named/named.ca See The named.ca File for additional information on the named.ca file. As long as you are internally consistent, you can name this file anything you want.

• /var/named/hosts See The hosts File for additional information on hosts files.

  The name hosts is a generic name indicating the file's purpose and content. But to avoid confusion with /etc/hosts, you should name this file something other than hosts. The most common naming convention is db.domainname. Thus, the hosts file for the doc.com domain would be called db.doc.

  If you have more than one zone, each zone must have its own hosts file and each of these zone hosts files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts file db.doc and the other db.sales.

• /var/named/hosts.rev See The hosts.rev File for additional information on the hosts.rev file.

  The name hosts.rev is a generic name indicating the file's purpose and content. If you have more than one zone, each zone must have its own hosts.rev file and each of these zone hosts.rev files must have a unique name. For example, if your DNS domain is divided into doc.com and sales.doc.com zones, you could name one hosts.rev file doc.rev and the other sales.rev.

• /var/named/named.local See The named.local File and for additional information on the named.local file. As long as you are internally consistent, you can name this file anything you want.

$INCLUDE Files

An include file is any file named in an $INCLUDE() statement in a DNS data file. $INCLUDE files can be used to separate different types of data into multiple files for your convenience. See $INCLUDE Files.

For reference purposes, the following table compares BIND file names from the above mentioned sources.

Domain Names

A domain name is the name assigned to a group of systems on a local network that share DNS administrative files. A domain name is required for the network information service database to work properly.

Default Domain Name

DNS obtains your default domain name from your resolv.conf file.

• If the resolv.conf file is not available, or does not identify a default domain, and if your enterprise-level naming service is either NIS+ or NIS, the Sun implementation of DNS obtains the default domain name from those services.

• If resolv.conf is not available or does not provide a domain name and you are not running either NIS+ or NIS, you must either provide a resolv.conf file on each machine that does specify the domain or set the LOCALDOMAIN environment variable.

Trailing Dots in Domain Names

When working with DNS-related files, follow these rules regarding the trailing dot in domain names:

• Use a trailing dot in domain names in hosts, hosts.rev, named.ca, and named.local data files. For example, sales.doc.com. is correct for these files.

• Do not use a trailing dot in domain names in named.boot or resolv.conf files. For example, sales.doc.com is correct for these files.

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. It is a set of dynamic 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.

The DNS name server uses several files to load its database. At the resolver level, it needs the file /etc/resolv.conf listing the addresses of the servers where it can obtain its information. The resolver reads this resolv.conf file to find the name of the local domain and the location of name servers. It sets the local domain name and instructs the resolver routines to query the listed name servers for information. Normally, each DNS client system on your network has a resolv.conf file in its /etc directory. If a client does not have a resolv.conf file, it defaults to using a server at IP address 127.0.0.1.

Whenever the resolver has to find the IP address of a host (or the host name corresponding to an address), the resolver builds a query package and sends it to the name servers listed in /etc/resolv.conf. The servers either answer the query locally or contact other servers known to them, ultimately returning the answer to the resolver.

When a machine's /etc/nsswitch.conf file specifies hosts: dns (or any other variant that includes dns in the hosts line), the resolver libraries are automatically used. If the nsswitch.conf file specifies some other naming service before dns, that naming service is consulted first for host information and only if that naming service does not find the host in question are the resolver libraries used.

For example, if the hosts line in the nsswitch.conf file specifies hosts: nisplus dns, the NIS+ naming service will first be searched for host information. If the information is not found in NIS+, then the DNS resolver is used. Since naming services such as NIS+ and NIS only contain information about hosts in their own network, the effect of a hosts:nisplus dns line in a switch file is to specify the use of NIS+ for local host information and DNS for information on remote hosts out on the Internet.

There are two kinds of DNS clients.

• Client-only

  A client-only DNS client does not run in.named. Instead, it consults the resolver. The resolver knows about a list of name servers for the domain, to which queries are then directed.

• Client-server

  A client-server uses the services provided by in.named to resolve queries forwarded to it by client-machine resolvers.

The resolv.conf File

For a detailed description of what the resolv.conf file does, see resolv.conf(4).

See Setting Up the resolv.conf File for a discussion on how to set up the resolv.conf file.

The named.conf File

BIND 8.1 added a new configuration file, /etc/named.conf, that replaces the /etc/named.boot file. The /etc/named.conf file establishes the server as a master, slave, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.

The /etc/named.conf file contains statements that implement:

• Security through an access control list (ACL) that defines a collection of IP addresses that an NIS+ host can read and write

• Logging specifications

• Selectively applied options for a set of zones, rather than to all zones

The configuration file is read by in.named when the daemon is started by the server's startup script, /etc/init.d/inetsvc. The configuration file directs in.named to other servers or to local data files for a specified domain.

The named.conf file contains statements and comments. Statements end with a semicolon. Some statements can contain a block of statements. Again, each statement in the block is terminated with a semicolon.

Example 3–1 Example Master Configuration File for a Master Server

options {
         directory "/var/named";
         datasize 2098;
         forward only;
         forwarders {
                  99.11.33.44;
         };
         recursion no;
         transfers-in 10;
         transfers-per-ns 2;
         allow-transfer {
                  127.0.1.1/24;
         };
};
 
logging {
         category queries { default_syslog; };
};
 
include "/var/named/abcZones.conf"
 
 
// here are the names of the master files
zone "cities.zn" {
         type master;
         file "db.cities.zn";
};
 
zone "0.0.127.in-addr.arpa" {
         type master;
         file "db.127.cities.zn";
};
 
zone "168.192.in-addr.arpa" {
         type master;
         file "db.cities.zn.rev";
};
 
zone "sales.doc.com" {
         type slave;
         file "slave/db.sales.doc";
         masters {
                  192.168.1.151;
         };
};
 
 
zone "168.192.in-addr.arpa" {
	         type slave;
         file "slave/db.sales.doc.rev";
         masters {
                  192.168.1.151;
         };
};

DNS Hierarchy in a Local Domain

If your company is large enough, it might support a number of domains, organized into a local namespace. The following figure 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 subdomains, sales.ajax.com, test.ajax.com, and manf.ajax.com.

Figure 3–3 Hierarchy of DNS Domains in a Single Organization

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 the following figure is a “leaf” of the huge DNS namespace supported on the global Internet.

It consists of the root directory, represented as a dot (.), and two top level domain hierarchies, one organizational and one geographical. Note that the com domain introduced in this figure is one of a number of top-level organizational domains in existence on the Internet.

Figure 3–4 Hierarchy of Internet Domains

At the present time, the organizational hierarchy divides its namespace into the top-level domains listed shown in the following table. It is probable that additional top-level organizational domains will be added in the future.

The geographic hierarchy assigns each country in the world a two or three-letter 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 domains (organizational and geographical) are maintained by the various Internet governing bodies. People with networks of any size can “join” the Internet by registering their domain name in either the organizational or the geographical hierarchy.

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

To join the Internet, do the following.

• Register your DNS domain name with the an appropriate Internet governing body.

• Obtain a network IP address from that governing body.

There are two ways to accomplish this.

• You can communicate directly with the appropriate Internet governing body or their agent.

• You can contract with an Internet Service Provider (ISP) to assist you. ISPs provide a wide range of services from consulting to actually hosting your Internet presence.

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 added to the name of the Internet hierarchy to which it belongs. For example, the ajax domain shown in Figure 3–5 has been registered as part of the Internet com hierarchy. Therefore, its Internet domain name becomes ajax.com.

The following figure shows the position of the ajax.com domain in the DNS namespace on the Internet.

Figure 3–5 Ajax Domain's Position in the DNS Namespace

The ajax.com subdomains now have the following names.

sales.ajax.com
test.ajax.com
 manf.ajax.com

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

boss.manf.ajax.com
quota.sales.ajax.com

The Internet organization 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 ajax.com domain and delegates authority over the names in that domain. The ajax.com domain, in turn, assigns names to the hosts in its domain and approves the formation of the sales.ajax.com, test.ajax.com, and manf.ajax.com domains.

Fully Qualified Domain Names (FQDNs)

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 following syntax.

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

ajax.com. 
sales.ajax.com. 
test.ajax.com. 
manf.ajax.com.

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

Zones

DNS service for a domain is managed on the set of name servers. Name servers can manage a single domains 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. Therefore, the name server is said to be authoritative for the zone. If you are responsible for a particular name server, you might be given the title “Zone Administrator”.

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 to connect to a remote host using a host name by a utility like ftp or telnet, DNS performs name-to-address mapping, by looking up the host name in the zone file and converting it into its IP address.

Figure 3–6 Domains and Zones

For example, the Ajax domain shown in the above contains a top domain (Ajax), four subdomains, and five sub-subdomains. It is divided into four zones.. Thus, the Ajax name server administers a zone composed of the Ajax, Sales, Retail, and Wholesale domains. The Manf 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 includes 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 more 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.168.21.165. In the in-addr.arpa zone files, its address is listed as 165.21.168.192.in-addr.arpa. with the dot at the end indicating the root of the in-addr.arpa domain.