The Domain Name System (DNS) translates domain names to IP addresses on a network. Domain names remember the IP addresses. For example, you might not be able to remember 63.251.56.142 as a Web site address, but you can easily remember its domain name www.apache.org.
To connect two computers in a Linux network, you need to install the DNS service on a Linux server.
This ReferencePoint describes how to configure the DNS server on a Linux server. It also provides an overview to Berkeley Internet Domain (BIND), the original implementation of DNS.
DNS Overview
DNS is an Applications Layer protocol in the TCP/IP protocol suite. DNS uses the TCP and User Datagram Protocol (UDP).
In a system that does not have DNS on a Linux server, a hosts file is maintained. This hosts file stores the mapping of host names to IP addresses in all Unix variants and in all Linux systems.
The hosts File
The /etc/hosts file must be present on every TCP/IP host. Any change in the host name to IP address mapping requires updating this file on every host. The structure of the hosts files is shown in Listing 1-2-1:
 |
# Table of IP addresses and Host names
#
127.0.0.1 localhost
164.100.24.213 diamond
164.100.24.193 ruby
164.100.24.194 pearl
164.100.24.180 amethyst butterfly
164.100.24.181 topaz
164.100.24.200 emerald spider
164.100.24.208 lapislazuli
164.100.24.195 garnet jade
|
In the above listing, lines that begin with the HASH sign (#) are comments. All other lines define data for the host table. A data line begins with an IP address and is followed by a list of host names, which map to that IP address. A host may be assigned more than one name. Additional names are known as aliases.
Listing 1-2-1 shows the primary name assigned to an IP address, which is the first name in the list.
| Note | The host file maintenance is cumbersome because you need to update every host file in a network when new hosts are registered with InterNIC. As a result, DNS is preferred. |
DNS Architecture
DNS is a hierarchical database of host information. Figure 1-2-1 depicts the DNS architecture:
The root divides into top-level domains such as org, com, mil, and edu. The root level is served by a number of root servers.
The top level of the domain in the DNS architecture is defined below the root level and is divided into domains and subdomains. Each subdomain is assigned a name that is up to 63 characters long. DNS allows nesting of up to 127 domains in a single tree. A domain name specification relative to the root domain is known as a Fully Qualified Domain Name (FQDN).
The top level also contains many servers, each of which maintains a partition of the DNS database. For example, there is stones.org, which is an imaginary domain created under the org domain. The stones domain can have its own authoritative server for its domain.
The stones domain may contain the subdomains jade, diamond, and ruby. The subdomain jade.stones.org may have a separate name server, while the name server that serves stones.org, may also serve diamond.stones.org and ruby.stones.org.
The stones zone includes both diamond and ruby subdomains, while the jade zone includes jade.stones.org. The zones of authority have to be assigned during the set up of the name servers. The name server for more than one zone can be authoritative. Figure 1-2-2 shows the differences between a zone, a domain, and a subdomain:
The Role of DNS on the Internet
DNS is a distributed database and requires minimal centralized maintenance. Local servers on a network do not need to maintain complete copies of a database; they can get the information whenever they need it. The server just needs to know the location of the DNS root servers, which is provided by the DNS administrator. Thereafter, the process of finding information is automatic because the server knows how to follow up the links through different levels of the DNS hierarchy.
There are 13 servers that provide root service. Table 1-2-1 lists the servers named from a.root-servers.net through m.root-servers.net:
| Name | Organization | URL |
|---|---|---|
| A | VeriSign Global Registry Services | |
| B | Information Sciences Institute, University of Southern California | |
| C | Cogent Communications | |
| D | University of Maryland | |
| E | National Aeronautics and Space Administration | |
| F | Internet Software Consortium | |
| G | Defense Information Systems Agency | |
| H | Army Research Laboratory | |
| I | Autonomica | |
| J | VeriSign Global Registry Services | |
| K | RIPE-NCC | |
| L | Internet Corporation for Assigned Names and Numbers | |
| M | WIDE |
Open table as spreadsheetThe domain name information about a remote server starts with the local name server. If on receiving a query, the local name server is aware of the solution, it answers the query itself. If it is unable to do so, it seeks the help of the root servers listed in Table 1-2-1. The root server does not answer the query itself; it points to the server responsible for that remote domain to the local server.
On receiving the information from the root server, the local server sends the query directly to the remote server. The remote server answers the query after being contacted by the local server. The remote server may not be the server responsible for the domain about which the local server is seeking information.
Due to the hierarchical structure of the DNS, the remote server knows about the systems in its subdomain. The local server receives the final answer and holds the pointers to the remote servers, which are responsible for the queried domain.
The local server saves the information about the remote server and uses it to query the domain, saving substantial time. This is known as caching. The cached information cannot remain on the local server for a long time. DNS allows the administrator of a domain to make a decision about how long the cached data may be retained.
Figure 1-2-3 illustrates the above process:
 "Click To expand")
BIND Program
BIND is an implementation of the DNS protocols. It provides an open redistributable implementation of the DNS components, a DNS server known as named, a DNS resolver library, and tools to verify the operation of the DNS server.
The BIND DNS server is used on name serving computers on the Internet, providing a stable naming architecture. The resolver library included in the BIND distribution provides the standard APIs for translation between domain names and Internet addresses.
BIND is ported onto the UNIX and Linux Operating Systems. There are two units in BIND - the resolver or the client side of the system and named or the server daemon.
Installing BIND
On Red Hat Linux, the rpm program can be used to install the BIND software. It contains various options.
The query option, –q, ascertains the availability of the BIND software in the system. The following explains the query option –q:
[root]# rpm –q bind
bind-8.1.2-1
The option –U of the rpm program is used to upgrade the existing BIND software as shown:
[root]# rpm -U bind-8.2.2_P3-1.i386.rpm
warning : /etc/rc.d/rc5.d/K45named saved as /etc/rc.d/rc5.d/K45named.rpm
Managing the named Daemon
The named daemon is the server side daemon of the BIND software. The configuration file is named.conf in the /etc directory. The named daemon starts during the boot process. The named script, which starts the named daemon, resides in the /etc/rc.d/init.d.
The command to start or stop the named daemon on a running computer:
[root]# ndc stop
[root]# ndc start
new pid is 899
A program known as the named control program (ndc) controls the named daemon. This program is installed along with the BIND software. You can use this program to restart a killed process:
[root]# ndc restart
new pid is 915
The ndc program contains a Help command that shows the list of options. Listing 1-2-2 shows the list of options:
|
[root] # ndc
Type help -or- /h if you need help.
ndc> /h
/h(elp) this text
/e(xit) leave this program
/t(race) toggle tracing (protocol and system events)
/d(ebug) toggle debugging (internal program events)
/q(uiet) toggle quietude (prompts and results)
/s(ilent) toggle silence (suppresses nonfatal errors)
ndc> /t
tracing now on
ndc> /e
|
The above listing shows a list of options.
Configuring the Resolver
The resolver is located on every client and server and resolves host names into IP addresses. It is configured in the file known as /etc/resolv.conf. This file is automatically created when the Linux operating system is installed on a system.
The Structure and Configuration of the resolv.conf File
The resolv.conf is a text file and can be edited with a text editor, such as vi. The resolver reads this file every time it starts.
Each line in the resolv.conf file can contain exactly one configuration command. A configuration command starts with a keyword that defines the purpose of the command. This keyword, in turn, is followed by one or more configuration values.
Configuration commands such as nameserver and domain accept only a single value after the keyword. Commands such as search, option, and sortlist can accept a list of values.
The nameserver Command
The nameserver command defines the name servers that are used by the resolver. If the nameserver command is absent, the resolv.conf files assumes that name server is running on a local host.
An excerpt from resolv.conf file:
nameserver 164.100.24.213
nameserver 164.100.24.180
nameserver 164.100.24.196
The above excerpt indicates the order in which name servers will be queried to resolve a domain name.
The domain Command
The domain command defines a default domain. The resolv.conf file can contain only one instance of the domain command. The following example shows the instance of a domain:
domain jade.stones.org
The search Command
The search command defines the list of domains to search when resolving a name. It can accept up to six domain names. It can even accept domain names that are not related to the existing network.
The following is an example of the search command:
search jade.stones.org amethyst.stones.org stones.org
| Note | Use either the domain command or the search command in the resolv.conf file. The domain and search commands are mutually exclusive. As a result, if both are present, the one that appears last will override the other. |
The sortlist Command
The sortlist command defines a list of preferred networks for a returned address. It enables you to give preference to certain IP addresses over others.
An example of the sortlist command is:
sortlist { 164.100.24.0/24; 164.100.30.0/16 }
The parameters passed with the sortlist command are the addresses of the preferred network on which you want the address returned.
The options Command
The options command processes various options for the resolver. Table 1-2-2 lists these options and their functions:
| Options | Functions |
|---|---|
| Debug | Turns on the RES_DEBUG resolver option that enables resolver debugging. |
| ndot:n | Specifies that for a domain name with n or more periods in it, the resolver searches for the domain name before applying the search list. |
| timeout:n | Sets the initial query timeout for the resolver. |
| attempts:n | Sets the number of times that a query request is retried by a resolver. |
| Round-robin | Selects the name servers on a round-robin basis. |
| no-check-names | Disables the compliance with RFC952. |
| inet6 | Queries for 128-bit Ipv6 addresses. |
BIND Configurations
The resolver and the named daemon combine to create a variety of configurations. These provide the infrastructure that builds the DNS of an organization.
The basic configurations of BIND are:
-
Caching-only server
-
Secondary or slave server
-
Resolve-only BIND configuration
-
Master server
| Note | The caching-only server does not have authority over any zone. This server handles query requests sent by local hosts on a network. It also tracks down answers and stores them in its cache. Queries that cannot be answered from the cache of a server are sent to an authoritative server, such as the master or secondary server. |
A secondary server functions as the backup server of its zone. It loads the entire database from the master server and stores a copy of the zone on its local disk. If the master server is down for repairs or is offline for administrative purposes, the secondary server can act as the master server for a zone. The secondary server contains the latest information of a zone downloaded from the master server.
A master server acts as the source for all information pertaining to a zone. The master server also loads the zone database, created by the domain administrator, from local disk files. Every zone should have a single master server.
Caching-Only Server Configuration
The caching-only server uses the named.conf file for configuration. This file is read during the boot procedure by the named daemon.
| Note | The secondary and master servers also use the named.conf file for configuration. |
Listing 1-2-3 shows the contents of the named.conf file:
|
options {
directory "/var/named" ;
};
// a caching only name server configuration
zone "." {
type hint;
file "named.ca" ;
};
zone "0.0.127 . in-addr.arpa " {
type master;
file "named.local" ;
};
|
In the above listing, a single options statement always begins the named.conf file. The curly brackets in the options statement contain a keyword followed by its parameters. An example is:
options {
directory "/var/named" ;
}
In the above example, the keyword directory defines the /var/named directory. This is the default directory for the named daemon.
Zone statements in the Listing 1-2-3 define a zone for which a name server is authoritative. It defines the type of the server, master or secondary. It also provides information about the files that act as the sources of domain-related information. The zone statement is followed by ".", which is the root domain. Each zone statement begins with the zone command. It is followed by two clauses, type and file.
The type clause can have the following values:
-
master: Defines the master server.
-
slave: Defines the secondary server.
-
hint: Defines the hint file used. The hint file contains the names and IP addresses of the root servers.
-
stub: Defines a stub server that holds only names of the name servers.
The first zone statement in Listing 1-2-3 indicates that the type is hint. It also identifies the hint file required to initialize the name server during the booting process of the Linux Operating System.
The hint file addressed in Listing 1-2-3 is named.ca and contains the names and addresses of root name servers. The named.ca file contains information that the named daemon uses to start a cache.
The columns in Listing 1-2-4 shows the contents of the named.ca file:
|
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET 3600000 A 198.41.0.4
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET 3600000 A 128.9.0.107
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET 3600000 A 192.33.4.12
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET 3600000 A 128.8.10.90
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET 3600000 A 192.203.230.10
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET 3600000 A 192.5.5.241
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET 3600000 A 192.112.36.4
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET 3600000 A 128.63.2.53
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET 3600000 A 192.36.148.17
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET 3600000 A 198.41.0.10
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET 3600000 A 193.0.14.129
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET 3600000 A 198.32.64.12
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET 3600000 A 202.12.27.33
|
The second zone statement in the Listing 1-2-4 identifies the domain as 0.0.127.in-addr.arpa. This is a special name assigned to a loopback domain. The file clause identifies the file name as named.local. The named.local file is the repository of domain information for the domain, 0.0.127.in-addr.arpa.
The domain 0.0.127.in-addr.arpa is a reverse-lookup domain that translates the IP address 127.0.0.1 to the host name localhost. Listing 1-2-5 shows the localhost file of Red Hat Linux:
|
cat /var/named/named.local
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
|
In the above listing, IN, SOA, NS, and PTR are Resource Records (RRs), where IN is an Internet Record, NS is a Name Server, SOA is the State of Authority, and PTR is the Pointer Record. The RR provides the default setting for the whole zone and informs the secondary server when the zone transfer should happen.
Secondary Server Configuration
The secondary server also uses the named.conf file for configuration.
Listing 1-2-6 shows the contents of the named.conf file for secondary configuration on the emerald server. Diamond is the master server for the stones.org domain and configures emerald as a secondary server for these domains.
|
options {
directory "/var/named" ;
};
// a Slave or Secondary Server DNS configuration
zone "." {
type hint;
file "named.ca" ;
};
zone "0.0.127.in-addr.arpa; {
type master;
file "named.local" ;
};
zone "stones.org" {
type slave;
file "stones.hosts";
masters { 164.100.24.213; };
};
zone 100.164. in-addr.arpa; {
type slave;
file " 100.164.reverse";
masters { 164.100.24.213; };
|
The first three statements of the listing are similar to the caching-only server configuration. Two new zone statements for the domains stones.org and 100.164.in-addr.arpa are included, as shown in Listing 1-2-7:
|
zone "stones.org" {
type slave;
file "stones.hosts";
masters { 164.100.24.213; };
zone 100.164. in-addr.arpa; {
type slave;
file " 100.164.reverse";
masters { 164.100.24.213; };
|
The file clause in above listing identifies the local storage for the zone information as stones.hosts.
The masters clause in the Listing 1-2-7 identifies the source of the zone information, 164.100.24.213. The secondary server will download the entire zone file from the master server and then store the information in stones.hosts file.
The file 100.164.reverse is the repository for the 164.100.0.0 reverse domain information.
| Note | Listing 1-2-6 uses four configuration files. The secondary server does not start another zone transfer until the master server updates its own zone. |
Resolve-Only BIND Configuration
The resolve-only BIND configuration is applicable for Linux clients. In this configuration, either the default resolv.conf file is used or some configuration changes are applied to this file and then used.
Master Server Configuration
The named.conf file is used for master server configuration.
Listing 1-2-8 shows the named.conf file for master server configuration:
|
Options {
Directory "/var/named"
// a master name server configuration
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127 . in-addr.arpa" {
type master;
file "named.local";
};
zone "stones.org" {
type master;
file "stones.hosts";
};
zone "100.164 . in-addr.arpa: {
type master;
file "164.100.reverse";
};
|
In the above listing, the named.conf file, stones.org, and 100.164.in-addr.arpa declare their respective zones and indicate the master server for those zones. The file clause indicates the files that contain the database records for the specified zones.
DNS Resource Records
There are six RRs that are used to build DNS database records.
-
Start of Authority (SOA): This record provides information about the DNS name server, which helps other hosts and DNS daemons to check with the master daemon for updates.
-
Name Server (NS): This record identifies the authoritative name server for a zone and helps the parent domain server to know about the other servers that exist in its subdomain. The NS record must be included in the stones.hosts file because it identifies the name server of a domain.
-
Address (A): This record maps host names to IP addresses.
-
Pointer (PTR): This record maps IP addresses to host names.
-
Canonical Names (CNAME): This record associates an alias to the official name of a host.
-
Mail Exchanger or MX: This record identifies where to deliver mail for a specific domain.
The Fields of the Resource Records
The following structure is common to all RRs:
[name] {TTL} {class} type data
The name field can refer to an individual host or to a whole domain.
Time To Live (TTL) field indicates the time in seconds for which RRs should be cached. The TTL value can be fixed depending upon the importance of the information.
The class field contains the value IN indicating an Internet address class.
| Note | The content of the data field depends on the type of resource record. |
Zone File Directives
There are four file directives that simplify the complexity of zone files. These files also define a value used by a RR in a zone file.
Table 1-2-3 lists the four directives and their functions:
| Directive | Function |
|---|---|
| $TTL | Defines the default TTL, if the RR in a zone file does not specify how long the remote servers should cache answers from a zone— no explicit TTL is mentioned. |
| $ORIGIN | Sets the current origin, which is a domain name that is used by any relative domain to complete. |
| $INCLUDE | Divides a large domain into different files to ease the administration of a domain. This directive can even be used to support multiple domains in a single zone. |
| $GENERATE | Enables the creation of a series of NS, CNAME, or PTR RRs. |
Zone Files
The zone files used by named daemon are configured in the named.conf configuration file. Here, the zone files are stones.hosts and 164.100.reverse.
The stones.hosts File
The name of the zone file for the domain stones.org is stones.hosts. The contents for the stones.hosts file is shown in Listing 1-2-9.
|
$ TTL 86400
;
;
; The stones.org domain database
@ SOA diamond.foobirds.org. sysadmin.diamond.foobirds. org. (
2000020602 ; Serial
21600 ; Refresh
1800 ; Retry
604800 ; Expire
900 ) ; Negative cache TTL
;Define the nameservers
NS diamond.stones.org.
NS amethyst.stones.org.
;Define the mail servers
MX 10 diamond.stones.org.
MX 20 amethyst.stones.org.0
;
;
;Define a localhost
localhost A 127.0.0.1
;
;Define the hosts in this zone
diamond A 164.100.24.213
pearl A 164.100.24.193
amethyst A 164.100.24.180
emerald A 164.100.24.200
garnet A 164.100.24.195
ruby A 164.100.24.193
MX 5 diamond.stones.org.
topaz A 164.100.24.181
MX 5 diamond.stones.org.
spider CNAME emerald.stones.org.
|
In the above listing, the stones.hosts file opens with the $TTL statement. The $TTL statement sets the default TTL for all RRs for one day.
The SOA is the first RR with which all zone files begin. The SOA RR provides information to external servers about the zone, that is, the name of the master server. It also provides information needed by the secondary servers to begin the process of database synchronization. @ indicates the current origin that is stones.org. The SOA RR consists of various data field components. Table 1-2-4 identifies the data field components:
| Data Field Components of the SOA RR | Functions |
|---|---|
| diamond.stones.org | Name of the master server for a zone. |
| sysadmin.diamond.org | E-mail address of a domain administrator. |
| 2000020602 | A numerical value that tells the secondary server that the zone information is updated. |
| 21600 | Duration of refresh cycle; after every such cycle the secondary server checks whether the zone information in the master server is updated. |
| 1800 | Duration of retry cycle. |
| 604800 | Expiration time value. |
| 900 | TTL for negative caching. |
The remaining contents of the stones.hosts file shown in Listing 1-2-9 can be divided into four sections:
-
Name Server
-
Mail Server
-
Host Information
-
Alias
The following shows the Name Server section of the stones.hosts file:
;Define the name servers
NS diamond.stones.org.
NS amethyst.stones.org.
The NS RR specifies the name servers of a domain. It provides the official name servers for a domain.
The following shows the Mail Server section of the stones.hosts file:
;Define the mail servers
MX 10 diamond.stones.org.
MX 20 amethyst.stones.org.
The first record indicates that the server diamond.stones.org is the mail server with a preference of 10 for the stones.org domain. The second record assigns the server amethyst.stones.org the status of a backup mail server with a preference of 20.
The Host Information section of the stones.hosts file is listed in Table 1-2-5:
| Domain | Type | Data |
|---|---|---|
| Diamond | A | 164.100.24.213 |
| Pearl | A | 164.100.24.193 |
| Amethyst | A | 164.100.24.180 |
| Emerald | A | 164.100.24.200 |
| Garnet | A | 164.100.24.195 |
| Ruby | A | 164.100.24.193 |
In Listing 1-2-9, the DNS provides a host name to every IP address. The bulk of the contents of the zone file consists of A records, which performs the requisite mapping of hostname to IP address:
Spider CNAME emerald.stones.org.
The CNAME RR facilitates the use of alias or nicknames. The name field on CNAME contains the host alias as spider and the data field contains the official name of the host as emerald.stones.org.
The 164.100.reverse File
The 164.100.reverse file does the reverse of the domain database - it translates IP addresses to host names. Listing 1-2-10 shows the 164.100.reverse file:
|
; Address to host name mappings.
;
$ TTL 1d
@ SOA diamond.foobirds.org. sysadmin.diamond.foobirds. org. (
2000021602 ; Serial
21600 ; Refresh
1800 ; Retry
604800 ; Expire
900 ) ; Negative cache TTL
NS diamond.stones.org.
NS amethyst.stones.org.
24.213 PTR diamond.stones.org.
24.193 PTR ruby.stones.org.
24.180 PTR amethyst.stones.org.
24.181 PTR topaz.stones.org.
24.200 PTR emerald.stones.org.
24.195 PTR garnet.stones.org.
|
In the above listing, all the entries are same as the stones.hosts file except PTR RR. The IP to host name mapping is carried out by PTR records.
Security of the DNS Server
Any damage to the DNS server will reflect directly on the systems present on a network. To prevent any kind of unauthorized access, you must be equipped with the current hardware and software devices.
Securing the Linux System
To prevent unauthorized access in a Linux system, secure the single user mode because an unauthorized person can harm the DNS database by rebooting the server in single mode. To prevent this, you can apply certain changes to the lilo.conf file, as shown in Listing 1-2-11:
|
# global section
boot = /dev/hda2
prompt
timeout = 60
# default boot image
image = /boot/vmlinuz-2.2.5-15
label = linux
root = /dev/hda2
read-only
password = Trek?Trel?
restricted
|
The above listing shows the changes to be applied to the lilo.conf file to lessen the chance that an unauthorized person will successfully reboot the server in single user mode.
| Note | Various sites on the Internet provide ample information on the possible loopholes in the Linux system:
|
Securing the DNS Server with BIND8
The BIND configuration provides options to limit access to zone transfers to authorized servers only.
Restricting Zone Transfers
Laxity allows outsiders to access information in a zone through a zone file transfer. You can restrict their access by modifying the named.conf file. Listing 1-2-12 shows the modified file used to restrict zone transfers:
|
$ nslookup
Default server : diamond.stones.org
Address: 164.100.24.213
> ls stones.org
[diamond.stones.org]
$ORIGIN stones.org
ruby 1D IN A 164.100.24.193
topaz 1D IN A 164.100.24.181
emerald 1D IN A 164.100.24.200
lapislazuli 1D IN A 164.100.24.208
localhost 1D IN A 127.0.0.1
|
In the above listing, the named.conf file on diamond.stones.org is shown. You can modify this listing by adding the allow-transfer option. This option defines the access control list for zone transfers.
The allow-transfer option can be placed in the options statement to control zone transfer for the entire server. The hosts listed in the allow-transfer option are permitted to transfer the zone. In the above listing, only one host is permitted to transfer the zone. All other hosts are blocked.
Listing 1-2-13 shows the named.conf file after the addition of the allow-transfer option to zone statements for stones.org and the 100.164.in-addr.arpa domains:
|
Options {
Directory "/var/named";
};
zone "." {
type hint;
file "named.ca" ;
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local" ;
};
zone "stones.org" {
type master
file "stones.org" ;
allow-transfer { 164.100.24.196;};
};
zone "100.164.in-addr.arpa" {
type master;
file "164.100.reverse" ;
allow transfer { 164.100.24.208;};
};
|
The above listing shows the named.conf file after the addition of the allow-transfer option.
When the nslookup command is executed, the output will be:
$ nslookup
Default server : diamond.stones.org
Address: 164.100.24.213
> ls stones.org
[diamond.stones.org]
*** Can’t list domain stones.org ; Unspecified error
> exit
Running named Daemon Without Root Privileges
To keep intruders from breaking into the network:
-
Run the named daemon with fewer privileges. By default, named daemon runs as a process owned by a root user. Any intruder getting control of the named daemon will automatically get the root privileges and can create havoc on the server.
-
Create a new user ID and a group ID. The new group id should not be shared with any other user or process.
-
All the files required by named daemon should have read and write privileges for the new user id.
Note The named daemon does not have the privileges of the root account and runs under a different user id. This minimizes the chances of damage in case of an attack.
Running named Daemon in chroot Jail
The chroot Jail command creates a private file system that isolates a program from all other information in the file system, increasing system security.
A minimal copy of the root file system is created to run named daemon in chroot Jail. The copies of /dev, /etc, /usr, and /var directories are included.
Use the following with the chroot Jail command:
-
The /dev directory must have null device, /dev/null.
-
The /etc directory should have named.conf and resolv.conf files. It should also contain the /etc/group and /etc/passwd directories. It should also have a copy of the /etc/localtime directory, which is used by named daemon for the timestamp of log entries.
-
The /usr directory must contain DNS programs. Create a /usr/sbin directory, a copy of the named-xfer program, and a statically linked copy of the named daemon.
After the private root is created, run named with –t option to point it to the chroot Jail command. For example, if the minimal copy of the root is created in the /home2/named directory, then run named with this command:
[root]# named –t /home2/named
DNS with ipchains
The rules defined in an ipchains command to accept DNS traffic specify the source of the traffic with the –s option, and the destination with the –d option. The action that should happen for the matching port and address parameters is specified with the –j option. For example:
ipchains -A input –d 164.100.24.208 53 -j accept
The above rule indicates that the traffic is bound for port 53 on the host with IP address 164.100.24.208. If this condition is true, then the traffic is accepted.
DNS Security Protocols
DNS Security (DNSSEC) adds data authentication and integrity services that enhance the DNS protocol.
Troubleshooting DNS
You can troubleshoot DNS using troubleshooting utilities included in the BIND package. The commands are host, nslookup, and Domain Information Groper (dig).
The host Command
The host command is used to get the IP address of a host name.
Syntax of the host command is:
host [-w] [-v] [-r] [-l] [-t type] [-a] name [server]
Table 1-2-6 lists the options used and Their functions:
| Options | Functions |
|---|---|
| -w | Causes the host command to wait for response from a server. |
| -v | Causes the host command to produce the output. |
| -d | Turns on the debugger. |
| -l | Lists the complete domain by performing a zone file transfer. |
| -a | Requests all records for the domain name in verbose format. |
| name | Defines the name of the domain object for which information is sought. |
| server | Defines the name of the server to which a query should be sent. |
| -t type | Requests a specific type of RR. |
| -r | Causes the host to send a nonrecursive query to the server. |
The dig Command
The dig command is used to gather information from name servers. It contains two modes:
-
Simple interactive mode for a single query.
-
Batch mode that executes a query in a list of several queries.
A simple dig command provides information section-wise. It helps in troubleshooting of DNS servers, both local and remote. Listing 1-2-14 shows this section-wise information:
|
[toby] dig –x 164.100.24.193
; <<>> DiG 8.2 <<>> -x
; ; got answer:
; ; ->>HEADER<<- opcod: QUERY, status: NOERROR, id: 6
; ; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,ADDITIONAL: 1
; ;QUERY SECTION:
; ; 193.24.100.164.in-addr.arpa, type = ANY, class = IN
; ; ANSWER SECTION:
193.24.100.164.in-addr.arpa. 1D IN PTR ruby.stones.org.
; ; AUTHORITY SECTION:
100.164.in-addr.arpa. 1D IN NS diamond.stones.org
; ; ADDITIONAL SECTION
diamond.stones.org 1D IN A 164.100.24.213
; ; Total query time: 1msec
; ; FROM: 24seven.arabiannights.com to SERVER: default -- 0.0.0.0
; ; WHEN: Wed Jun 12 16:40:23 2002
; ; MSG SIZE sent: 42 rcvd: 129
|
The above listing shows the section-wise information of the dig command and its output.
Table 1-2-7 lists the sections of the listing:
| Section | Description |
|---|---|
| Query Section | Type = A indicates that it is a request for the network address, and IN specifies that it should be an Internet address. |
| Answer Section | Presents the domain name with the IP address fetched from the DNS server. |
| Authority Section | Contains the name that was the target of the query; IN indicates that it is an Internet server. |
| Additional Section | Contains one entry of the authoritative server. |
| Total query time | Indicates the time elapsed between the time the query was sent and the response was received. |
| Msg Size | Specifies the total number of bytes transmitted and received. |
The nslookup Command
This command can manually look up host names. It is used to debug network-related problems and ensures that the DNS is set properly.
The nslookup command, shown in Listing 1-2-15, runs interactively:
|
[toby]$ nslookup
Default Server: diamond.stones.org
Address: 164.100.24.213
> ruby.stones.org
Server: diamond.stones.org
Address: 164.100.24.213
> exit
|
The above listing shows the nslookup command that can be used to manually view host names.
BIND Log and Information Files
BIND can use the syslogd facility to log files. BIND also supplies a utility known as ndc to create information files. The ndc and syslogd log files are used to monitor the overall health of a system.
The log files indicate the work load currently being handled by a server. These files are a good source of information on system status and health. The size of the log files needs monitoring because they tend to grow over time and waste considerable disk space.
Contents of named_dump.db File
Issuing the following command produces the named_dump.db file:
[root]# ndc dumpdb
Database dump initiated.
The dump file is written to the file named_dump.db in /var/named directory.
Table 1-2-8 lists the sections in the named_dump.db file:
| Section | Description |
|---|---|
| Zone Table Section | Stores the information about every zone for which the server has authority. The values from SOA record of each zone are displayed. |
| Hints Section | Contains the list of root name servers loaded from the hint file. |
| Cache and Data Section | Contains cache information; most of the information is loaded from the local zone files. |
Contents of the named.stats File
The named.stats log file captures name server statistics. You can use this command to write this file to the /var/named directory:
[root]# ndc stats
Statistics dump initiated.
This file is important because it is used to identify redundant query types.
