Configuring a DNS Server

Now that we ve examined DNS from a client viewpoint, and explored concepts like SOAs, IP-to-address mapping, and address-to-IP mapping, it should be obvious what kind of services a DNS server needs to provide to clients . In addition, DNS servers need to be able to support both primary and secondary services as described earlier.

The Berkeley Internet Daemon (BIND) is the most commonly used DNS server for Solaris. It is supplied in a package that is generally installed during the initial system configuration. Its main configuration file is /etc/named.conf for BIND 8 supplied with Solaris 9.

Caution  

BIND 4 and earlier used a configuration file called /etc/named.boot; however, these versions are no longer supported by the ISC, and administrators running BIND 4 should upgrade to BIND 8 or 9.

The /etc/named.conf file is responsible for controlling the behavior of the DNS servers and provides the following keywords, which are used to define operational statements:

acl	Defines an access control list that determines which clients can use the server.
include	Reads an external file that contains statements in the same format as /etc/named.conf . This is very useful when your configuration file becomes very large, as different sections can be divided into logically related files.
logging	Determines which activities of the server are logged in the log file specified by the statement.
options	Defines local server operational characteristics.
server	Defines operational characteristics of other servers.
zone	Creates local DNS zones.

Let s examine a sample statement involving each of these keywords.

acl

If we want to define an access control list for all hosts on the local network (10.24.58.*), we would insert this statement:

 acl local_network { 10.24.58/24 }; 

Here, 24 indicates the netmask 255.255.255.0 in prefix notation. Now, if our router was the host 10.24.58.32, and we wanted to prevent any access to the DNS server from that address, we would amend the previous statement to the following:

 acl local_network { !10.24.58.32; 10.24.58/24 }; 

Note that the negation of a specific address from a subnet that is also permitted must precede the definition of that subnet in the statement.

include

A little later, we ll examine how to configure DNS zones. Since these definitions can be very long for large networks, administrators often place them in a separate file so that they can be managed separately from ACL definitions and system options. Thus, to include all of the zone definitions from the file /var/named/zones.conf , we would insert the following statement into the /etc/named.conf file:

 include "/var/named/zones.conf" 

options

The options section sets key parameters that affect the runtime behavior of the BIND server. Typically, these are the directories in which the zone databases are stored, and the file in which the process ID of the named process is stored. The following example gives the standard options for BIND 8:

 options { directory "/var/named"; pid-file "/var/named/pid"; } 

server

The server statement defines characteristics of remote name servers. There are two main options that can be set with a server statement: whether or not a remote server is known to transmit incorrect information, and whether or not the remote server can answer multiple queries during a single request. A sample server statement would look like this:

 server 10.24.58.32 {      bogus yes;      transfer-format many-answers; } 

zone

A zone must be created for each network or subdomain that your DNS server manages . Zones can either be created as primary or secondary, depending on which server is authoritative for a particular domain. Entries for IP-to-name and name-to-IP mappings must also be included to correctly resolve both IP address and domain names . For the domain cassowary.net , the following zone entries would need to be created:

 zone "cassowary.net" {      type master;      file "cassowary.net.db"; } zone "58.24.10.in-addr.arpa" {      type master;      file "cassowary.net.rev"; } 

In this case, the two zone files /var/named/cassowary.net.db and /var/named/cassowary .net.rev need to be populated with host information. A sample /var/named/cassowary.net .db file would contain SOA entries like this:

 @    IN    SOA    cassowary.net.    root.cassowary.net.    (         2000011103  ;serial number         10800       ;refresh every three hours         1800        ;retry every 30 mins         1209600     ;Two week expiry         604800)     ;Minimum one week expiry         IN    NS    ns.cassowary.net.         IN    MX    10    firewall.cassowary.net.         firewall    IN    A    10.24.58.1    ;firewall         natalie         IN    A    10.24.58.2    ;webserver         catherine       IN    A    10.24.58.3    ;webserver         tazdevil    IN    A    10.24.58.4    ;kerberos         security    IN    CNAME    tazdevil 

A sample /var/named/cassowary.net.rev file would contain SOA entries like this:

 @    IN    SOA    58.24.10.in-addr.arpa.    root.cassowary.net.  (         2000011103   ;serial number         10800        ;refresh every three hours         1800         ;retry every 30 mins         1209600      ;Two week expiry         604800)      ;Minimum one week expiry         IN    NS     ns.cassowary.net. 1       IN    PTR    firewall.cassowary.net. 2       IN    PTR    natalie.cassowary.net. 3       IN    PTR    catherine.cassowary.net. 4       IN    PTR    tazdevil.cassowary.net. 

Each host within the domain must have an IP-to-domain mapping as well as a domain-to-IP mapping. Once a change is made to the zone file, the serial number should be incremented as appropriate. Note that in addition to address (A) and pointer (PTR) records for IP address and domain names, it is also possible to identify hosts as mail exchangers (MX) and by canonical names (CNAME). The former is required to define which host is responsible for handling mail within a domain, while the latter is used to create aliases for specific machines (thus, the tazdevil Kerberos server is also known as security.cassowary.net ).