In TCP/IP networks, each network interface (for example, an Ethernet card on a host computer) is identified by an IP address. Because IP addresses are hard to remember, an association is made between an easy-to-remember name and the IP address-much like the association between a name and a telephone number. For example, instead of having to remember that the IP address of Red Hat's Web server is 216.148.218.195, you can simply refer to that host by its name,
www.redhat.com . When you type www.redhat.com as the URL in a Web browser, the name
www.redhat.com has to be translated into its corresponding IP address. This is where the concept of DNS comes in.
DNS is a distributed, hierarchical database that holds information about computers on the Internet. The information includes the hostname, the IP address, and mail routing information. This information resides in many DNS hosts on the Internet; that's why the DNS database is called a distributed database. The primary job of DNS is to associate hostnames to IP addresses and vice versa.
In ARPANET-the precursor to today's Internet, the association between hostnames and IP addresses was maintained in a text file named
HOSTS.TXT , which was managed centrally and distributed to each host. As the number of hosts grew, it became clear that a static host table was unreasonable. DNS was proposed by Paul Mockapetris to alleviate the problems associated with using a static host table. As formally documented in RFCs 882 and 883 (November 1983), DNS introduced two key concepts:
Use of hierarchical domain names, such as
www.ee.umd.edu and
www.redhat.com
Distributed responsibility for managing the host database by using DNS servers throughout the Internet
DNS, as we know it today, is an Internet standard documented in RFCs 1034 and 1035. The standard has been updated and extended by several other RFCs-1101, 1183, 1348, 1876, 1982, 1996, 2065, 2181, 2136, 2308, 2535, 2845, 2929, 2930, 2931, 3007, 3008, 3090, 3110, and 3130. The earlier updates define data encoding, whereas later ones focus on improving DNS security. To read these and other RFCs online, visit Ohio State University's Internet RFC page at
DNS defines the following:
A hierarchical domain-naming system for hosts
A distributed database that associates a name with an IP address
Library routines that network applications can use to query the distributed DNS database (this library is called the resolver library)
A protocol for DNS clients and servers to exchange information about names and IP addresses
Nowadays, all hosts on the Internet rely on DNS to access various Internet services on remote hosts. As you may know from personal experience, when you obtain Internet access from an Internet service provider (ISP), the ISP provides you with the IP addresses of name servers. These are the DNS servers your system accesses whenever hostnames have to be mapped to IP addresses.
If you have a small LAN, you may decide to run a DNS server on one of the hosts or to use the name servers provided by the ISP. For medium-sized networks with several subnets, you can run a DNS server on each subnet to provide efficient DNS lookups. On a large corporate network, the corporate domain (such as
microsoft.com ) is further subdivided into a hierarchy of subdomains, and several DNS servers may be used in each subdomain.
The following sections provide an overview of the hierarchical domain-naming convention, and describe BIND-the implementation of DNS used on most UNIX systems, including Red Hat Linux.
DNS uses a hierarchical tree of domains to organize the namespace-the entire set of names. Each higher-level domain has authority over its lower-level subdomains. Each domain represents a distinct block of the namespace and is managed by a single administrative authority. Figure 18-1 illustrates the hierarchical organization of the DNS namespace.
Figure 18-1: Sample Domain Names Illustrating the Hierarchical DNS Namespace.
The root of the tree is called the root domain and is represented by a single dot (
. ). The top-level, or root-level, domains come next. The top-level domains are further divided into second-level domains, which, in turn, can be broken into further subdomains.
The top-level domains are relatively fixed and include well-known domains such as
com ,
net ,
org ,
edu ,
gov , and
mil . These are the commonly used top-level domains in the United States. These top-level domains came about as the Internet became widely used in the early 1990s. More recently, however, there have been many newer top-level domains such as
aero ,
biz ,
coop ,
info ,
museum , and
name . To learn about these and other top-level domains, visit
http://www.iana.org/gtld/gtld .
There is another set of top-level domain names for the countries, called country code domains. These domain names use the two-letter country codes assigned by the International Organization for Standardization (abbreviated as ISO, see
http:// www.iso.ch/ ). For example, the top-level country code domain for the United States is
us . In the United States, many local governments and organizations use the
us domain. For example,
mcps.k12.md.us is the domain name of the Montgomery County Public Schools in the state of Maryland in United States. To see a list of the top-level country code domain names, please see
http://www.iana.org/cctld/cctld-whois .
The fully qualified domain name (FQDN) is constructed by stringing together the sub- domain names, from lower to higher level, using dots (
. ) as separators. For example,
REDHAT.COM is a fully qualified domain name; so is
EE.UMD.EDU . Note that each of these may also refer to a specific host computer. Figure 18-2 illustrates the components of a fully qualified domain name.
Figure 18-2: Components of a Fully Qualified Domain Name.
Domain names are case insensitive. Therefore, as far as DNS is concerned, the domains
UMD.EDU and
umd.edu both represent University of Maryland's domain. The norm, however, is to type domain names in all lowercase.
Most UNIX systems, including Red Hat Linux, come with the BIND system-a well-known implementation of DNS. The BIND software is installed during Red Hat Linux installation, as long as you select the DNS Name Server package group when selecting the packages for installation.
To see which version of BIND is installed on your Red Hat Linux system, type the following command:
rpm -q bind bind-9.2.1-16
As the output shows, BIND Version 9.2.1 is installed on my system.
BIND includes three major components:
The
named daemon-the name server- that responds to queries about hostnames and IP addresses
A resolver library that applications can use to resolve hostnames into IP addresses and vice versa
Command-line DNS utility programs (DNS clients), such as dig (Domain Internet Groper) and host, that users can use to query DNS
The next few sections describe these components of BIND. Later sections describe how to configure the resolver and the name server.
This chapter only briefly describes DNS and BIND, but entire books have been devoted solely to them. For example, DNS and BIND, 4th Edition, by Paul Albitz and Cricket Liu (O'Reilly & Associates, April 2001), can help you learn more about DNS and BIND.
BIND also comes with a lot of online documentation that's installed on your Red Hat Linux system when you install the DNS Name Server package group. To read the online documentation about BIND, change the current directory with the command
cd/usr/share/doc/bind* (the directory name depends on which version of BIND is installed on your system), and look at the files in that directory.
The Internet Software Consortium (ISC)-a nonprofit corporation-supports BIND. Visit their website at
http://www.isc.org/ to learn more about the latest release of BIND.
To ask questions online about DNS and BIND, or to participate in related discussions, read the following newsgroups (see Chapter 16 for more information about reading newsgroups):
comp.protocols.dns.bind-Discussions about using BIND
comp.protocols.dns.ops-Discussions about DNS operations
comp.protocols.dns.std-Discussions about DNS standards
The
named daemon is the name server that responds to queries about hostnames and IP addresses. Based on the configuration files and the local DNS database, named either provides answers to queries or asks other servers and caches their responses. The named server also performs a function referred to as zone transfer, which involves copying data among the name servers in a domain.
The
named name server can be configured to operate in one of three modes:
Primary or Master-This is the authoritative name server that keeps the master copy of the domain's data on disk. There is one primary server for each domain or subdomain.
Secondary or Slave-A secondary name server copies its domain's data from the primary server using a zone transfer operation. There can be one or more secondary name servers for a domain.
Caching-A caching name server loads the addresses of a few authoritative servers for the root domain and gets all domain data by caching responses to queries resolved by contacting other name servers. Primary and secondary servers also cache responses. The Time To Live (TTL) field associated with each resource record controls the length of time for which a record may be retained in the cache of a caching name server. As you see later in this chapter, you can easily extend a caching-only name server into a primary name server.
A name server can be authoritative or not. As the term implies, the response from an authoritative name server is supposed to be accurate. The primary and secondary name servers are authoritative for their own domains, but they are not authoritative for responses provided from cached information. Caching name servers are never authoritative because all of their responses come from cached information.
To run a name server on your Red Hat Linux system, you have to run
named with the appropriate configuration files. Later in this chapter, you learn about the configuration files and data files that control how the name server operates.
Finding an IP address for a hostname is referred to as resolving the hostname. Network-aware applications, such as a Web browser or an FTP client, use a resolver library to perform the conversion from the name to an IP address. Depending on the settings in the
/etc/host.conf file, the resolver library consults the
/etc/hosts file or makes a DNS query to resolve a hostname to its IP address. The resolver library queries the name servers listed in the
/etc/resolv.conf file.
You do not need to learn much about the resolver library unless you are writing network-aware applications. To run Internet services properly, all you need to learn is how to configure the resolver. Subsequent sections in this chapter show you how to configure this and other aspects of DNS.
You can use the DNS utility programs-dig and host-to try out DNS from the shell prompt interactively. These utility programs are DNS clients. You can use them to query the DNS database and debug any name server you might set up on your system. By default, these programs query the name server listed in your system's
/etc/resolv.conf file.
You can use dig, the Domain Internet Groper program, to look up IP addresses for a domain name or vice versa. For example, to look up the IP address of
addlab.nws .noaa.gov , type:
dig addlab.nws.noaa.gov
dig prints the results of the DNS query with a great amount of detail. Here's the output of that
dig command on my Red Hat Linux system:
; <<>> DiG 9.2.1 <<>> addlab.nws.noaa.gov ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18561 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6 ;; QUESTION SECTION: ;addlab.nws.noaa.gov. IN A ;; ANSWER SECTION: addlab.nws.noaa.gov. 86400 IN A 140.90.141.131 ;; AUTHORITY SECTION: nws.noaa.gov. 86400 IN NS netinfo.hqnoc.noaa.gov. nws.noaa.gov. 86400 IN NS ns3.noc.noaa.gov. nws.noaa.gov. 86400 IN NS nwrns.noaa.gov. nws.noaa.gov. 86400 IN NS serns.noaa.gov. nws.noaa.gov. 86400 IN NS merns.noaa.gov. nws.noaa.gov. 86400 IN NS mwrns.noaa.gov. ;; ADDITIONAL SECTION: netinfo.hqnoc.noaa.gov. 86400 IN A 140.90.148.33 ns3.noc.noaa.gov. 86400 IN A 140.90.143.33 nwrns.noaa.gov. 67000 IN A 161.55.32.3 serns.noaa.gov. 69806 IN A 192.111.123.245 merns.noaa.gov. 68814 IN A 192.94.173.133 mwrns.noaa.gov. 68801 IN A 140.172.253.1 ;; Query time: 50 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sun Feb 16 17:59:12 2003 ;; MSG SIZE rcvd: 279
The answer you are looking for-the IP address of the host-is in the in the part of the output labeled
ANSWER SECTION: . Here's what that section looks like for this sample query:
;; ANSWER SECTION: addlab.nws.noaa.gov. 86400 IN A 140.90.141.131
Thus, the IP address of
addlab.nws.noaa.gov is
140.90.141.131 . The other sections in dig's output shows details such as the server it queried, the authoritative name servers for the hostname it queried, the time it took to perform the query, and so on. In this example, the
SERVER line near the end of dig's output shows that dig queries the name server at the IP address
192.168.0.1 -that's the first name server listed in my system's
/etc/resolv .conf file.
Reverse lookups (finding hostnames for IP addresses) are also easy with dig. All you have to do is use dig with the
-x option. For example, to find the hostname corresponding to the IP address 140.90.141.131, type the following:
dig -x 140.90.141.131
On my system, the output from this query looks like this:
; <<>> DiG 9.2.1 <<>> -x 140.90.141.131 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22285 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6 ;; QUESTION SECTION: ;131.141.90.140.in-addr.arpa. IN PTR ;; ANSWER SECTION: 131.141.90.140.in-addr.arpa. 86400 IN PTR addlab.nws.noaa.gov. ;; AUTHORITY SECTION: 141.90.140.in-addr.arpa. 86400 IN NS merns.noaa.gov. 141.90.140.in-addr.arpa. 86400 IN NS mwrns.noaa.gov. 141.90.140.in-addr.arpa. 86400 IN NS nwrns.noaa.gov. 141.90.140.in-addr.arpa. 86400 IN NS serns.noaa.gov. 141.90.140.in-addr.arpa. 86400 IN NS netinfo.hqnoc.noaa.gov. 141.90.140.in-addr.arpa. 86400 IN NS ns3.noc.noaa.gov. ;; ADDITIONAL SECTION: ns3.noc.noaa.gov. 86400 IN A 140.90.143.33 merns.noaa.gov. 86400 IN A 192.94.173.133 mwrns.noaa.gov. 86400 IN A 140.172.253.1 nwrns.noaa.gov. 86400 IN A 161.55.32.3 serns.noaa.gov. 86400 IN A 192.111.123.245 netinfo.hqnoc.noaa.gov. 86400 IN A 140.90.148.33 ;; Query time: 56 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sun Feb 16 18:03:06 2003 ;; MSG SIZE rcvd: 304
As you can see, dig prints a lot of information in addition to the result. The answer you want comes right after the label
ANSWER SECTION: , which in this case shows the hostname to be
addlab.nws.noaa.gov .
You can use dig to query other types of DNS records than name-to-address and address-to-name lookups. For example, DNS also contains mail exchanger (record type MX) to enable delivery of mail to a specific doman. The MX record instructs querying computers where to send messages meant for a domain. To look up an MX record for a host, simply prefix the hostname with the record type. Here is an example that queries the MX record for the domain name
comcast.net :
dig MX comcast.net
Here's the resulting output on my system:
; <<>> DiG 9.2.1 <<>> MX comcast.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34566 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;comcast.net. IN MX ;; ANSWER SECTION: comcast.net. 229297 IN MX 0 mx00.comcast.net. ;; AUTHORITY SECTION: comcast.net. 12924 IN NS NS01.JDC01.PA.comcast.net. comcast.net. 12924 IN NS NS02.JDC01.PA.comcast.net. ;; ADDITIONAL SECTION: mx00.comcast.net. 5742 IN A 24.153.64.1 NS01.JDC01.PA.comcast.net. 6437 IN A 66.45.25.71 NS02.JDC01.PA.comcast.net. 2332 IN A 66.45.25.72 ;; Query time: 1459 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sun Feb 16 18:05:21 2003 ;; MSG SIZE rcvd: 145
Again, the
ANSWER SECTION shows the MX record, which says that mail addressed to
comcast.net should be sent to
mx00.comcast.net .
You can also query DNS by using the
host command. The host program produces output in a compact format. For example, here's a typical use of host to look up information about a host:
host www.gao.gov www.gao.gov has address 161.203.16.2
By default, host prints the IP address and any MX record (these records list the names of mail handlers for the host).
For a reverse lookup, use the
-t ptr option, along with the IP address as an argument, as follows:
host -t ptr 161.203.16.2 2.16.203.161.in-addr.arpa. domain name pointer www.gao.gov.
In this case, host prints the PTR record that shows the hostname corresponding to the specified IP address.
You can also try other types of records, such as
CNAME (for canonical name), as follows:
host -t cname www.ee.umd.edu www.ee.umd.edu. is an alias for www.ece.umd.edu.
This indicates that the canonical name for
www.ee.umd.edu is
You configure DNS by using a number of configuration files. The exact set of files depends on whether or not you are running a name server and, if so, the type of name server-caching or primary. Some configuration files are needed whether you run a name server or not.
You do not need a name server running on your system to use the DNS clients-dig and host. You can use them to query one of your domain's name servers. Typically, your ISP provides you with this information. You have to list the IP addresses of these name servers in the
/etc/resolv.conf file-the resolver library reads this file to determine how to resolve hostnames. The format of this file is
domain your-domain.com search your-domain.com nameserver A.B.C.D nameserver X.Y.Z.W
where
A.B.C.D and
X.Y.Z.W are the IP addresses (dotted-decimal IP addresses, such as 192.168.0.1) of the primary and secondary name servers your ISP provides you.
The
domain line in
/etc/resolv.conf lists the local domain name. The
search line specifies the domains on which a hostname is searched first (usually, you put your own domain in the search line). The domain listed on the
search line is appended to any hostname before the resolver library tries to resolve it. For example, if the
search line contains
your-domain.com , then when you look for a host named
mailhost , the resolver library first tries
mailhost.your-domain.com; if that fails, it tries
mailhost . The
search line applies to any hostname you try to access. For example, if you are trying to access
www.redhat.com , the resolver first tries
www.redhat.com.your-domain.com and then
www.redhat.com .
Another important configuration file is
/etc/host.conf -this file tells the resolver what to do when attempting to resolve a hostname. A typical
/etc/host/conf file contains the following line:
order hosts,bind
This tells the resolver to consult the
/etc/hosts file first and, if that fails, to query the name server listed in the
/etc/resolv.conf file. As explained in Chapter 6, the
/etc/hosts file associates IP addresses to hostnames. A typical line from the
/etc/hosts file looks like the following:
127.0.0.1 lnbp200 localhost.localdomain localhost
This line says that the IP address 127.0.0.1 is assigned to the hostnames
lnbp200 ,
localhost.localdomain , and
| Insider Insight |
In the latest version of Linux, which uses GNU C Library version 2 (glibc 2) or later, the name service switch (NSS) file, /etc/nsswitch.conf , specifies how services such as the resolver library, NIS, NIS+, and local files such as /etc/hosts and /etc/shadow interact. For example, the following hosts entry in the /etc/nsswitch.conf file specifies that the resolver library should first try the /etc/hosts file, then try NIS+, and finally try DNS: hosts: files nisplus dns To learn more about the /etc/nsswitch.conf file and what it does, type info libc "Name Service Switch" at the shell prompt in a terminal window. |
A simple, but useful name server is one that finds answers to hostname queries by using other name servers and then remembers the answer (by saving it in a cache) the next time you need it. This can shorten the time it takes to access hosts you have accessed recently because the answer is already in the cache.
When you install the DNS Name Server package group during Red Hat Linux installation, the configuration files for a caching name server are also installed. That means you can start running the caching name server without much work on your part. This section describes the configuration files and what you have to do to start the caching name server.
The first configuration file you need is
/etc/named.conf . The named server reads this configuration file when it starts. You already have this file if you have installed the DNS Name Server when you installed Red Hat Linux in Chapter 2. Here's what the default
/etc/named.conf file contains:
// generated by named-bootconf.pl
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
include "/etc/rndc.key";
Comments are C-style (
/* ... */ ) or C++-style (start with
// ). The file contains block statements enclosed in curly braces (
{...} ) and terminated by a semicolon (
; ). A block statement, in turn, contains other statements, each ending with a semicolon.
This
/etc/named.conf file begins with an
options block statement with a number of option statements. The
directory option statement tells
named where to look for all other files that appear on file lines in the configuration file. In this case, named looks for the files in the
/var/named directory.
The
controls statement in
/etc/named.conf contains security information so that the
rndc command can connect to the
named service at port 953 and interact with
named . In this case, the
controls statement contains the following line:
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
This says the
rndc can connect from localhost with the key named
rndc (the file
/etc/rndc.key defines the key and the encryption algorithm to be used).
The
rndc (remote name daemon control) utility is a successor to the older
ndc (name daemon controller) utility used to control the named server by sending it messages over a special control channel, a TCP port where
named listens for messages. The
rndc utility uses a cryptographic key and authenticates itself to the
named server by using a fast MD5 secure hash algorithm called HMAC-MD5 (see RFCs 2085 and 2104 for more information on HMAC-MD5). The
named server has the same cryptographic key so that it can decode the authentication information sent by
rndc .
After the options and controls statements, the
/etc/named.conf file contains several
zone statements, each enclosed in curly braces and terminated by a semicolon. Each
zone statement defines a zone. The first
zone is named
"." (root zone); it's a hint zone that specifies the root name servers.
The next two
zone statements in
/etc/named.conf are master zones. The syntax for a master
zone statement for an Internet class zone (indicated by the IN keyword) is as follows:
zone "zone-name" IN {
type master;
file "zone-file";
[...other optional statements...]
};
The
zone-name is the name of the zone, and
zone-file is the zone file that contains the resource records (RR)-the database entries-for that zone.
The
/etc/named.conf file ends with an
include statement:
include "/etc/rndc.key";
This statement inserts the contents of the
/etc/rndc.key file into the
/etc/named.conf file. This enables you to place sensitive configuration data (such as encryption keys) in a separate file with appropriate permissions to prevent nonroot users from accessing it. In this case, the
/etc/rndc.key file contains the key named
rndc , which was referenced in the
options statement eariler in the
/etc/named.conf file. Here is what the key definition looks like:
key "rndckey" {
algorithm hmac-md5;
secret "AbigLongEncryptionKey";
};
The
algorithm option specifies the type of algorithm, which can be
dsa or
hmac-md5 . The
secret option specifies the encryption key.
| Insider Insight |
To generate your own HMAC-MD5 key, use the dnssec-keygen command with the following syntax: dnssec-keygen -a hmac-md5 -b 128 -n HOST yourhost.domain. You should replace yourhost.domain with your host's fully qualified domain name. The dnssec-keygen command generates two files whose names begin with K followed by the hostname. One of the files has a .key extension and the other .private. Use the cat command to look at the content of either file and copy the cryptic looking key to the secret option of the /etc/rndc.key file. |
The zone file typically starts with a number of directives, each of which begins with a dollar sign (
$ ) followed by a keyword. Two commonly used directives are
$TTL and
$ORIGIN .
For example, the line
$TTL 86400
uses the
$TTL directive to set the default time to live (TTL) for subsequent records with undefined TTLs. The value is in seconds, and the valid TTLs are in the range 0 to 2147483647 seconds. In this case, the directive sets the default TTL as
86400 seconds (or one day). The time specified in the time-to-live directive indicates how long the information in that record should be considered valid.
The
$ORIGIN directive sets the domain name that will be appended to any unqualified records. For example, the following
$ORIGIN directive sets the domain name to localhost:
$ORIGIN localhost.
| Insider Insight |
If there is no $ORIGIN directive, the initial $ORIGIN is the same as the zone name that comes after the zone keyword in the /etc/named.conf file. |
After the directives, the zone file contains one or more resource records. These records follow a specific format, which is outlined in the next section.
You have to understand the format of the resource records before you can understand and intelligently work with zone files. Each resource record has the following format (the optional fields are shown in square brackets):
[domain] [ttl] [class] type data [;comment]
In a resource record the fields are separated by tabs or spaces and may contain some special characters, such as an
@ symbol for the domain and a semicolon (
; ) to indicate the start of a comment.
The first field, which must begin at the first character of the line, identifies the domain. You can use the
@ symbol to use the current
$ORIGIN for the domain name for this record. If you have multiple records for the same domain name, leave the first field blank.
The optional
ttl field specifies the time to live-the duration for which the data can be cached and considered valid. You can specify the duration in one of the following formats:
N , where
N is a number meaning
N seconds
N
W , where
N is a number meaning
N weeks
N
D , where
N is a number meaning
N days
N
H , where
N is a number meaning
N hours
N
M , where
N is a number meaning
N minutes
N
S , where
N is a number meaning
N seconds
The letters
W ,
D ,
H ,
M , and
S can also be in lowercase. Thus, you can write
86400 or
1D (or
1d ) to indicate a duration of one day. You can also combine these to specify more precise durations, such as
5w6d16h to indicate 5 weeks, 6 days, and 16 hours.
The
class field specifies the network type. The most commonly used value for this field is
IN for Internet. Other values are
CH for ChaosNet (an obsolete network used long ago by Symbolics Lisp computers), and
HS for Hesiod (an NIS-like database service based on BIND).
Next in the resource record is the
type field, which denotes the type of record (such as
SOA ,
NS ,
A , or
PTR ). Table 18-1 lists many commonly used DNS resource record types. The data field comes next, and it depends on the type field.
|
Type |
Name |
Description |
|---|---|---|
|
A |
Address |
Specifies the host address corresponding to a name |
|
A |
IPv6 Address |
Specifies the IPv6 host address corresponding to a name |
|
CERT |
Digital Certificate |
Holds a digital certificate |
|
CNAME |
Canonical Name |
Defines the nickname or alias for a hostname |
|
DNAME |
Delegation Name |
Replaces specified domain name with another name to be looked up |
|
HINFO |
Host Info |
Identifies the hardware and operating system for a host |
|
KEY |
Public Key |
Stores a public key associated with a DNS name |
|
MX |
Mail Exchanger |
Identifies the host that accepts mail meant for a domain (used to route email) |
|
NS |
Name Server |
Identifies authoritative name servers for a zone |
|
PTR |
Pointer |
Specifies the name corresponding to an address (used for reverse mapping-converting an IP address to a hostname) |
|
RP |
Responsible Person |
Provides the name of a technical contact for a domain |
|
SIG |
Signature |
Contains data authenticated in the secure DNS (see RFC 2535 for details) |
|
SOA |
Start of authority |
Indicates that all subsequent records are authoritative for this zone |
|
SRV |
Services |
Lists well-known network services provided by the domain |
|
TXT |
Text |
Used to include comments and other information in the DNS database |
|
WKS |
Well Known Services |
Lists services provided by a host (this has been deprecated and is no longer used) |
You should learn to read the resource records, at least the ones of type
SOA ,
NS ,
A ,
PTR , and
MX , which are some of the most commonly used. The next few sections briefly describe these records, illustrating each record type through an example.
A typical SOA record has the following format:
@ 1D IN SOA @ root ( 42 ; serial 3H ; refresh -- 3 hours 15M ; retry -- 15 minutes 1W ; expiry -- 1 week 1D ) ; minimum -- 1 day
The first field specifies the domain as an
@ , which means the current domain (by default, the zone name, as shown in the
/etc/named.conf file). The next field specifies a TTL of one day for this record. The class field is set to
IN , which means that the record is for Internet. The type field specifies the record type as SOA. The rest of the fields constitute the data for the SOA record. The data includes the name of the primary name server (in this case,
@ , or the current domain), the email address of the technical contact, and five different times enclosed in parentheses.
The NS record specifies the authoritative name servers for a zone. A typical NS record looks like the following:
. 3600000 IN NS A.ROOT-SERVERS.NET.
In this case, the NS record lists the authoritative name server for the root zone (notice that the name of the first field is a single dot). The TTL field specifies the record to be valid for 1,000 hours (3600000 seconds). The class is
IN , for Internet, and the record type is NS. The final field lists the name of the name server (
A.ROOT-SERVERS.NET. ), which ends with a dot.
An A record specifies the address corresponding to a name. For example, the following A record shows the address of
A.ROOT-SERVERS.NET . as
198.41.0.4 :
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
In this case, the network class is not specified because the field is optional, and the default is
IN .
PTR records are used for reverse mapping-converting an address to a name. Consider the following example:
1 IN PTR localhost.
This record comes from a file for a zone named
0.0.127.in-addr.arpa . Therefore, this record says that the name associated with the address 127.0.0.1 is
localhost .
An MX record specifies the name of a host that accepts mail on behalf of a specific domain. For example, here's a typical MX record:
naba IN MX 10 mailhub.lnbsoft.com.
This says that mail addressed to the hostnamed
naba in the current domain should be sent to
mailhub.lnbsoft.com (this host is called a mail exchanger). The number
10 is the preference value. For a list of multiple MX records with different preference values, the ones with lower preference values are tried first.
Now that you know a bit about resource records, you can go through the zone files for the caching name server.
Information about the root name servers is in the file
/var/named/named.ca , as specified in the
zone statement for the root zone in the
/etc/named.conf file. The following listing shows the
/var/named/named.ca file from a Red Hat Linux system:
; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . <file>" ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC ; under anonymous FTP as ; file /domain/named.cache ; on server FTP.INTERNIC.NET ; ; last update: Nov 5, 2002 ; related version of root zone: 2002110501 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; operated by VeriSign, Inc. ; . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30 ; ; housed in LINX, operated by RIPE NCC ; . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129 ; ; operated by IANA ; . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File
This file contains NS and A resource records that specify the names of authoritative name servers and their addresses for the root zone (indicated by the '
. ' in the first field of each NS record).
The comment lines in the file begin with a semicolon. These comments give you hints about the location of the root name servers. There are 13 root name servers for the Internet, most of the root servers are located in the United States. This file is a necessity for any name server because the name server has to be able to reach at least one root name server.
The
/etc/named.conf file includes a
zone statement for the
localhost zone that specifies the zone file as
localhost.zone . That file is located in the
/var/named directory of your Red Hat Linux system. The
/var/named/localhost.zone file contains the following resource records:
$TTL 86400 $ORIGIN localhost. @ 1D IN SOA @ root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS @ 1D IN A 127.0.0.1
This zone file starts with a
$TTL directive that sets the default TTL to one day (86400 seconds) for subsequent records with undefined TTLs. Next, a
$ORIGIN directive sets the domain name to localhost.
After these two directives, the
/var/named/localhost.zone file contains three resource records (RRs): an SOA record, an NS record, and an A record. The SOA and the NS record specify the
localhost as the primary authoritative name server for the zone. The A record specifies the address of
localhost as
127.0.0.1 .
The third zone in the
/etc/named.conf file specifies a reverse-mapping zone named
0.0.127.in-addr.arpa . For this zone, the zone file is
/var/named/named.local , which contains the following:
$TTL 86400 @ IN SOA localhost. root.localhost. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS localhost. 1 IN PTR localhost.
The SOA and NS records specify
localhost as the primary name server.
| Insider Insight |
The SOA record also shows root.localhost. as the email address of the technical contact for the domain. Note that the DNS zone files use a user.host. format for the email address. When sending any email, you have to replace the first dot with an |
Now that you have studied the configuration files for the caching name server, you can start the name server and see it in operation. To start the name server, log in as
root and type the following command at the shell prompt:
service named start
This starts
named -the name server daemon.
| Insider Insight |
To ensure that the server starts every time you reboot the system, log in as root and type the following command: chkconfig --level 35 named on |
The named server writes diagnostic log messages in the
/var/log/messages file. After you start named, you can check the log messages by opening
/var/log/messages in a text editor. Following are some typical log messages from named when started on my Red Hat Linux system:
Feb 14 18:02:09 localhost named[16400]: starting BIND 9.2.1 -u named Feb 14 18:02:09 localhost named[16400]: using 1 CPU Feb 14 18:02:10 localhost named[16400]: loading configuration from '/etc/named.conf' Feb 14 18:02:10 localhost named: named startup succeeded Feb 14 18:02:10 localhost named[16400]: no IPv6 interfaces found Feb 14 18:02:10 localhost named[16400]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 14 18:02:10 localhost named[16400]: listening on IPv4 interface eth1, 192.168.0.7#53 Feb 14 18:02:10 localhost named[16400]: command channel listening on 127.0.0.1#953 Feb 14 18:02:10 localhost named[16400]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 Feb 14 18:02:10 localhost named[16400]: zone localhost/IN: loaded serial 42 Feb 14 18:02:10 localhost named[16400]: running
If there are no error messages from named, you can proceed to test the name server.
Now, you can use the
host command to test the name server. For example, to look up the IP address of
www.gao.gov by using the caching name server on
localhost , type the following command:
host www.gao.gov localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: www.gao.gov has address 161.203.16.2
As the output shows, the host command uses
localhost as the DNS server and returns the IP address of
| Insider Insight |
If you want to use the caching name server as your name server, you have to specify that name server as your primary one. To do this, make sure that the first line in the /etc/resolv.conf file is the following: nameserver 127.0.0.1 |
The best way to configure a primary name server is to start by configuring a caching name server, as explained in the previous sections. Then, add master zones for the domains for which you want this to be the primary name server. For example, suppose that I want to define a primary name server for the
naba.net domain. Here are the steps I go through to configure that primary name server (after I log in as
root ):
Add the following zone statements to
/etc/named.conf file:
zone "naba.net" IN {
type master;
file "naba.zone";
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "0.168.192.zone";
};
Create the zone file
var/named/naba.zone with the following lines in it:
$TTL 86400 $ORIGIN naba.net. @ 1D IN SOA @ root.naba.net ( 100 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS @ 1D IN A 192.168.0.7 wxp IN A 192.168.0.2
Create the zone file
var/named/0.168.192.zone with the following lines in it:
$TTL 86400 ; Remember zone name is: 0.168.192.in-addr.arpa @ IN SOA naba.net. root.naba.net ( 1 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS naba.net. 7 IN PTR naba.net. 2 IN PTR wxp.naba.net.
To test the new configuration, restart the named server with the following command:
service named restart
Now, use dig or host to query the DNS server. For example, here's how I use host to check the address of the host
wxp.naba.net at the DNS server running on
localhost :
host wxp.naba.net localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: wxp.naba.net has address 192.168.0.2
If you want to use dig to check the DNS server, type the following command:
dig @localhost wxp.naba.net
That
@localhost part specifies the DNS server that dig should contact.
Here is an example of when I try a reverse lookup with the IP address 192.168.0.2:
host 192.168.0.2 localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: 2.0.168.192.in-addr.arpa domain name pointer wxp.naba.net