The Domain Name System (DNS)





The Domain Name System (DNS)

To simplify the unwieldy state of computer naming, the Domain Name System (DNS) was created. It allows the master host database to be split up and distributed among multiple systems on the Internet. DNS uses a hierarchical database approach, creating levels of information that can be split and stored on various systems throughout the Internet.

In addition to splitting up the database, DNS also provides a means for clients to query the database in real time. All a client needs to know is the location of one DNS server (and maybe a backup or two) in the database hierarchy. If the client queries a DNS server with a hostname not stored on the DNS server’s local database, the server can query another DNS server that does have the information and forward it to the client.

To implement the DNS concept, a new database and protocol were created to pass DNS information among clients and servers and to enable DNS servers to update one another. This section describes the workings of the DNS system and how clients can query DNS servers for hostname information.

DNS Structure

The structure of a hierarchical database is similar to an organization chart with nodes connected in a treelike manner (that’s the hierarchical part). The top node is called the root. The root node does not explicitly show up in Internet host addresses, so it is often referred to as the “nameless” node. Multiple categories were created under the root level to divide the database into pieces called domains. Each domain contains DNS servers that are responsible for maintaining the database of computer names for that area of the database (that’s the distributed part). The diagram in Figure shows how the DNS domains are distributed.

Click To expand
Figure: The Internet DNS system

The first (or top) level of distribution is divided into domains based on country codes. Additional top-level domains for specific organizations were created to prevent the country domains from getting overcrowded. Figure describes the layout of the original top-level DNS domains.

Figure: DNS Original Top-Level Domain Names

Domain

Description

.com

Commercial organizations

.edu

Educational institutions

.mil

U.S. military sites

.gov

U.S. government organizations

.net

Internet Service Providers (ISPs)

.org

Nonprofit organizations

.us

Other U.S. organizations (such as local governments)

.ca

Canadian organizations

.de

German organizations

(other countries)

Organizations from other countries

Recently, new top-level domains have been added to the DNS system. These new top-level domains allow identification of particular industries worldwide, and not just within a particular country. Corporations within those industries can register hostnames within their particular industry. Figure shows the seven new top-level domains.

Figure: DNS Top-Level Domains Added in 2001

Domain

Description

.aero

Corporations in the air transport industry

.biz

Generic businesses

.coop

Cooperatives

.info

Unrestricted use

.museum

Museums

.name

Individuals

.pro

Professionals (doctors, lawyers, and so on)

As the Internet grows, the top-level domains are each divided into subdomains, or zones. Each zone is an independent domain in itself but relies on its parent domain for connectivity to the database. A parent zone must grant permission for a child zone to exist and is responsible for the child zone’s behavior (just as in real life). Each zone must have at least two DNS servers that maintain the DNS database for the zone.

The original DNS specifications stipulated that the DNS servers for a single zone must have separate connections to the Internet and be housed in separate locations for fault-tolerance purposes. Because of this stipulation, many organizations rely on other organizations to host their secondary and tertiary DNS servers.

Hosts within a zone add the domain name to their hostname to form a unique Internet name. Thus, computer fred in the smallorg.org domain would be called fred.smallorg.org. This convention can become a little confusing because a domain can contain hosts as well as zones.

For example, the smallorg.org domain can contain host fred.smallorg.org, as well as grant authority for zone acctg.smallorg.org to a subdomain, which in turn can contain another host barney.acctg.smallorg.org. Although this simplifies the database system, it makes finding hosts on the Internet more complicated. Figure shows an example of a domain and an associated subdomain.

Click To expand
Figure: A sample domain and subdomain on the Internet

Finding a Hostname in DNS

As mentioned, DNS enables clients to query a local DNS server to obtain hostname information. This process results in three possible scenarios for finding a hostname:

  • Finding a host within the local domain

  • Finding a remote host whose name is not on the local DNS server

  • Finding a remote host whose name is on the local DNS server cache

Local Domain Hostnames

The simplest model for finding a hostname is a client attempting to find the hostname of another system within its local domain. In this scenario, the client uses the local DNS server as its default DNS server and sends the DNS query for the local hostname. The DNS server finds the hostname in its database section and returns the result to the client. This process is demonstrated in Figure.

Click To expand
Figure: Client A is resolving a local hostname from the DNS server

Remote Domain Hostnames

When a client wants to resolve the hostname for a system in a remote domain, there can be two possible scenarios:

  • The remote hostname is not found on the local DNS server

  • The remote hostname is found on the local DNS server cache

Remote Host Not Found on the Local DNS Server

When the client sends a query to the local DNS server to resolve a hostname for a system not contained within the local DNS server’s database, the following actions occur:

  1. The local DNS server queries a root DNS server for the hostname.

  2. The root DNS server determines what domain the hostname should be found in and passes the request to a DNS server responsible for the host’s domain.

  3. The responsible local DNS server resolves the hostname to an IP address and returns the result to the root DNS server.

  4. The root DNS server passes the result back to the client’s local DNS server.

  5. The client’s local DNS server returns the resulting IP address to the client.

There’s a lot of work going on behind the scenes in this process, but the end result is that the client receives the proper IP address for the remote system—all the client had to do was send one query to the local DNS server.

Remote Host Found in the Local DNS Server Cache

One advantage offered by DNS is that when the local DNS server has to query a root DNS server for a remote hostname, it can store the result in a local cache. When a local client queries the local DNS server for a remote hostname about which the server already has information, the local DNS server can return the cached information without having to go out and query a root DNS server. This greatly improves the response time of the query for the client.

There is one caveat to this process. When the root DNS server returns the IP address information for a hostname, it includes a time to live (TTL) value (the period for which the hostname information should be kept in a local DNS server’s cache before expiring). The responsible local DNS server for the remote host sets this value. Depending on the volatility of local network hostnames, TTL values can be set anywhere from a few minutes to a few weeks. Once the TTL value has expired, the local DNS server must query the root DNS server when a new client query is received.

The DNS Database

Each DNS server is responsible for keeping track of the hostnames in its zone. To accomplish this, the DNS server must have a way to store host information in a database that can be queried by remote machines. The DNS database is a text file that consists of resource records (RRs) for hosts and network functions in the zone. The DNS server must run a DNS server software package to communicate the DNS information from the local domain database to remote DNS servers.

The DNS server’s database must define various types of network resources, such as:

  • The local domain definition

  • Each registered host in the domain

  • Common nicknames for hosts in the domain

  • Special services, such as DNS servers and mail servers

RR formats were created to track all the information required for the DNS server. Figure describes some of the basic RRs that a DNS database might contain.

Note 

DNS database design has become a critical matter for researchers who constantly want to add more information to the database and to control the security of the information that is there. New record types are continually being added to the DNS database, but those in Figure are the core records for establishing a zone in the DNS database.

Figure: Core DNS Database Records

Record Type

Description

SOA

Start of Authority

A

Internet address

NS

Name server

CNAME

Canonical name (nickname)

HINFO

Host information

MX

Mail server

PTR

Pointer (IP address)

There is one SOA record for the domain listed at the top of the database. Any other resource records for the domain can be added in any order after that. Each domain DNS server contains resource records for each registered host in the domain. The following sections describe the individual DNS record types in more detail.

Start of Authority Record (SOA)

Each database starts with an SOA record that defines the zone in which the database resides. The format for the SOA record is as follows:

domain name  [TTL] [class] SOA origin person (
          serial number
          refresh
          retry
          expire
          minimum)

domain name The name of the zone that is being defined. (The @ sign is often used as a placeholder to signify the computer’s default domain.)

TTL The length of time (in seconds) for which a requesting computer will keep any DNS information from this zone in its local name cache. Specifying this value is optional.

class The protocol being used (for hosts on the Internet, it will always be class IN, for Internet).

origin The name of the computer where the master zone database is located. A trailing period should be used after the hostname; otherwise, the local domain name will be appended to the hostname (of course, if you want to use that feature, omit the trailing period).

person An e-mail address of a person responsible for the zone. The format of this value is a little different from what you might be used to seeing. The @ sign has already been used to signify the default domain name, so it can’t be used in the mail address. Instead, a period is used. For example, instead of [email protected], you would use sysadm.smallorg.org. If there are any periods in the name part, they must be escaped out by using a backslash \. An example of this would be the address [email protected], which would translate to john\.jones.smallorg.org.

serial number A unique number that identifies the version of the zone database file. Often what is used here is the date created plus a version count (such as 200210151).

refresh The length of time (in seconds) a secondary DNS server should query a primary DNS server to check the SOA serial number. If the secondary server’s SOA serial number is different from the primary server’s, the secondary server will request an update to its database. One hour (3,600 seconds) is the common specification for this value.

retry The time (in seconds) after which a secondary DNS server should retry in the event of a failed database refresh attempt.

expire The period (in seconds) for which a secondary DNS server can use the data retrieved from the primary DNS server without getting refreshed. This value will usually be substantial, such as 3600000 (about 42 days).

minimum The length time (in seconds) that should be used as the TTL in all RRs in this zone. Usually 86,400 (1 day) is a good value.

Internet Address Record (A)

Each host in the zone defined by the database should have a valid A record to define its hostname to the Internet. The format for the A record is as follows:

host  [TTL]  [class]  A  address

host The fully qualified hostname for the computer (including the domain name).

address The IP address of the computer.

TTL and class These parameters are optional and have the same meaning as for the SOA record.

Canonical Name Record (CNAME)

In addition to a normal hostname, many computers also have nicknames. This is useful for identifying particular services without having to rename computers in the domain. For instance, you might assign the nickname www.smallorg.org to the host fred.acctg1.smallorg.org. The CNAME record links nicknames with the real hostname. The format of the CNAME record is as follows:

nickname  [TTL]  [class]  CNAME  hostname

The roles of the nickname and hostname parameters are fairly obvious. They represent the nickname assigned and the original hostname of the computer, respectively.

Here again, the TTL and class parameters are optional and have the same meaning as for the SOA record.

Name Server Record (NS)

Each zone should have at least two DNS servers. NS records are used to identify these servers to other DNS servers trying to resolve hostnames within the zone. The format of an NS record is as follows:

domain  [TTL]  [class]  NS  server

domain The domain name of the zone for which the DNS server is responsible. If it is blank, the NS record refers to the zone defined in the SOA record.

server The hostname of the DNS server. There should also be an associated A record in the database to identify the IP address of the hostname.

TTL and class Again, these parameters are optional and have the same meaning as for the SOA record.

Host Information Record (HINFO)

Additional information about a computer can be made available to DNS servers by using the HINFO record. The format of the HINFO record is as follows:

host  [TTL]  [class]  HINFO  hardware  software

host The hostname of the computer the information applies to.

hardware The type of hardware the computer is using.

software The OS type and version of the computer.

The TTL and class Again, these parameters are optional and have the same meaning as for the SOA record.

Pointer Record (PTR)

In addition to an A record, each computer in the zone should have a PTR record. This allows the DNS server to perform reverse queries from the IP address of the computer. Without the PTR information, remote servers could not determine the domain name where an IP address is located. The format of a PTR record is as follows:

IN-ADDR name  [TTL]  [class]  PTR  name

IN-ADDR name The reverse DNS name of the IP address. If that sounds confusing, it is. This name allows the DNS server to work its way backward from the IP address of the computer. The IN-ADDR.ARPA address is a special domain to support gateway location and Internet address to host mapping. Inverse queries are not necessary because the IP address is mapped to a fictitious hostname. Thus, the IN-ADDR name of a computer with IP address 192.168.0.1 would be 1.0.168.192.IN-ADDR.ARPA.

name The hostname of the computer as found in the A record.

TTL and class Again, these parameters are optional and have the same meaning as for the SOA record.

Mail Exchange Record (MX)

The MX record is used to signify a particular type of host in the domain. It instructs remote mail servers where to forward mail for the domain. The format of the MX record is as follows:

name  [TTL]  [class]  MX  preference  host

name The domain name (or the SOA domain if name is blank). This can also be a hostname if you want to redirect mail for a particular host in the network.

preference An integer signifying the order in which remote servers should try connecting if multiple mail servers are specified. The highest preference is 0, with decreasing preference represented by increasing numbers.

preference This feature is used to create primary and secondary mail servers for a domain. When a remote mail server queries the DNS server for a mail server responsible for the domain, the entire list of servers and preferences is sent. The remote mail server should attempt to connect to the highest priority mail server listed, and if that fails, continue down the list in order of preference.

host The hostname or IP address of the mail server. There should also be an associated A record to identify the IP address of the mail server.

TTL and class Again, these parameters are optional and have the same meaning as for the SOA record.

Warning 

Be careful about using CNAME entries as MX hosts. Some e-mail server packages cannot work properly with CNAME (nickname) hosts.

A Sample DNS Database

When an ISP hosts a company’s domain name, it will have records in its DNS database identifying the domain to the Internet. The SOA record will identify the domain name, but it will point to the ISP’s host as the authoritative host. The NS records for the domain will point to the ISP’s DNS servers. If the company has its own mail server, the MX record will point to it. If the ISP handles the e-mail server for the company, the MX records point to the ISP’s mail servers.

As far as the rest of the Internet is concerned, these computers are part of the company domain—even if they do not really exist on the company network but rather are located at the ISP. Listing 4.1 presents a sample ISP record of the domain definitions in its DNS database.

Listing 4.1: Sample DNS database entries
Start example
smallorg.org IN SOA  master.isp.net. postmaster.master.isp.net 
  postmaster.master.isp.net (
                1999080501  ;unique serial number
               8H    ; refresh rate
               2H    ;retry period
               1W    ; expiration period
               1D)    ; minimum
      NS  ns1.isp.net.  ;defines primary namserver
      NS  ns2.isp.net.  ;defines secondary nameserver
      MX  10 mail1.isp.net.  ; defines primary mail server
      MX  20 mail2.isp.net.  ; defines secondary mail server
 www   CNAME  host1.isp.net  ;defines a www server at the ISP
 ftp   CNAME  host1.isp.net  ; defines an FTP server at the ISP
  host1.isp.net  A  10.0.0.1
 1.0.0.10.IN-ADDR.ARPA  PTR  host1.isp.net  ; pointer for reverse DNS
End example

The first section of Listing 4.1 is the SOA record for the new domain. The ISP points the domain name smallorg.org to its server master.isp.net. Next, the primary and secondary DNS servers are defined using the NS record type. Following the NS records, the primary (mail1.isp.net) and secondary (mail2.isp.net) mail servers are defined with MX records. Because the preference number for the mail1.isp.net server is lower, it is considered the primary mail server. Any mail for the smallorg.org domain should be delivered to that server if it is available.

After the MX records, the CNAME record defines the hostname www.smallorg.org as a nickname that points to the ISP server, which hosts the company web pages. The address ftp.smallorg.org is also defined as a nickname pointing to the same ISP server, which also hosts the FTP site. Using alias addresses for web and FTP servers is a service that most ISPs provide to customers who cannot afford to have a dedicated connection to the Internet but want to provide web and FTP services to their customers.

The A and PTR recordsets provide the Internet hostname and IP address information for the ISP host so that remote clients can connect to this server.

Note 

PTR records are often placed in a separate database file on the server to help simplify the databases. This isn’t a problem in the Listing 4.1 example, which has just one PTR record, but it can be when there are dozens or hundreds of them.


 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows