DNS server | Linux Clustering With Csm and Gpfs

< Day Day Up >

This section provides basic information on how to set up a DNS server in CSM and GPFS installations. This section is not a complete reference for DNS, but rather covers those issues specific to these environments. Refer to DNS-specific documentation for further details.

Package description

Berkeley Internet Name Domain (BIND) is an implementation of the Domain Name System (DNS). The latest version can be found on the Internet Software Consortium (ISC) Web site at http://www.isc.org/products/BIND. It is an openly redistributable reference of the major components of the Domain Name System. It includes:

A Domain Name System server
A Domain Name System resolver library
Tools to verify the proper operation of the DNS server

At the writing of this book, the latest version of BIND is Version 9.2.0.

DNS installation

You can directly compile the source code from ISC, or you can simply use the BIND package present on the Red Hat CD-ROM. To install the RPM, mount your Red Hat CD-ROM and install these two packages:

# rpm -ivh bind-9.1.0-10.i386.rpm
# rpm -ivh bind-utils-9.1.0-10.i386.rpm

DNS configuration

To configure the DNS, edit the /etc/named.conf file. This file is composed of two parts. The first part refers to the general configuration parameters for the DNS server, like the directory where DNS zone configuration files are stored or the IP of the DNS servers to forward requests that cannot be resolved locally. The second part defines the zones for which the DNS server is authoritative (zones for which this DNS server acts as a primary or secondary server). For example:

0.0.127.in-addr.arpa.zone is for reverse localhost DNS resolution (127.0.0.0 subnet).
1.168.192.in-addr.arpa.zone is for our reverse network DNS resolution (192.168.1.0 subnet).
localhost.zone is for the direct localhost DNS resolution.
clus-lab.austin.ibm.com.zone is for our domain DNS resolution.

Example B-1 shows you the zones we have defined in our labs.

Example B-1: DNS zones - /etc/named.conf

 options {         directory "/var/named/";         forwarders {                 9.3.199.2;                 9.53.248.2;                 9.53.249.2;                 };         allow-query { 192.168.1.0/24;};         allow-recursion { 192.168.1.0/24;};         transfer-format one-answer; }; zone "0.0.127.in-addr.arpa" {        type master;        file "0.0.127.in-addr.arpa.zone";        allow-update { none;}; }; zone "1.168.192.in-addr.arpa" {        type master;        file "1.168.192.in-addr.arpa.zone";        allow-update { none;}; }; zone "localhost" {        type master;        file "localhost.zone";        allow-update { none;}; }; zone "clus-lab.austin.ibm.com" {        type master;        file "clus-lab.austin.ibm.com.zone";        allow-update { none;}; };

Once your /etc/named.conf file is correct, create your zone files in /var/named/.

Example B-2 on page 279 shows the DNS configuration used in our labs.

Example B-2: DNS zone files

 File /var/named/clus-labs.austin.ibm.com.zone $TTL 86400 @       IN      SOA headnode.clus-lab.austin.ibm.com root.headnode.clus-labs.austin.ibm.com (                         4       ; serial                         28800   ; refresh                         7200    ; retry                         604800  ; expire                         86400   ; minimum                         ) ; IP addresses of DNS servers for this zone ; NS means Name Server                 IN      NS      192.168.1.100 ; Mail server                 IN      MX      10 master ; Addresses records clsnode1        IN      A       192.168.1.201 clsnode2        IN      A       192.168.1.202 clsnode3        IN      A       192.168.1.203 clsnode4        IN      A       192.168.1.204 master          IN      A       192.168.1.100 mgtnode4        IN      A       192.168.1.154 consesp1        IN      A       192.168.1.155 ; Canonical names definitions headnode        IN      CNAME   master mail            IN      CNAME   master ftp             IN      CNAME   master File /var/named/1.168.192.in-addr.arpa.zone $TTL 86400 @       IN      SOA     headnode.clus-lab.austin.ibm.com root.headnode.clus-labs.austin.ibm.com (                         2      ; serial                         28800  ; refresh                         7200   ; retry                         604800 ; expire                         86400  ; minimum                         )         IN      NS      192.168.1.100 100     IN      PTR     master.clus-lab.austin.ibm.com. 201     IN      PTR     clsnode1.clus-lab.austin.ibm.com. 202     IN      PTR     clsnode2.clus-lab.austin.ibm.com. 203     IN      PTR     clsnode3.clus-lab.austin.ibm.com. 204     IN      PTR     clsnode4.clus-lab.austin.ibm.com.

The $TTL 86400 text in the first line defines the time-to-live of the resource records in the zone for entries where the time-to-live is not explicitly defined.
The second line defines the resource record (RR) Start of Authority (SOA) for the zone. The @ symbol is a reference to the zone name, and root.localhost describes the administrative contact for the zone, where the first dot (.) in the left should be exchanged by an @ to define the e-mail address. The numbers defined between the parenthesis, usually written one per line for better readability, define the following parameters: serial number of this zone file, refresh time, retry time (for failed refresh requests), expiration time, and minimum time-to-live for all entries in the zone.
The next line defines an IN NS resource record. Since there is indication as to what RR this is associated with, the system uses the last used, the zone itself. In this case, IN NS defines the IP addresses of the name servers for the zone.
The RR IN MX xx defines the different mail exchangers for the domain and their priority.
The next entries are IN A records, defining the IP address for a name (real host name of the host).
The RR IN CNAME defines the canonical name (alias) given to a host. For example, ftp.clus-labs.austin.ibm.com is an alias of the master.clus-labs.austin.ibm.com host.

Considerations when creating a zone file

The following is some basic information that should help you when creating your own zone files for internal domains. This is regarding references to other host names and how to use the serial numbers in the SOA resource record.

Serial numbers

The serial numbers defined in the SOA resource record for each zone are used for secondary servers to check if the zone has been changed. For that reason, every time a zone file has been changed, the serial number must change also. To ease management, there are some patterns that can be used for serial numbers. One example is to create the serial numbers using the date of the last change in the file: YYYYMMDD##, where YYYY is the current year, MM the current month, DD the current day, and ## the sequence of changes. Every time you change this file, this serial number should be changed to reflect the date. If the last change occurred days before, just change the date and set ## to 01. If the last change occurred today, just add one to ##.

References to other host names

You can define NS, MX, or any other RR referring to names, but you should take care of how you write the names. If the referenced name is in this same zone, you could write only the host name of the system, as defined in its IN A record. If the referenced host is in another zone, wherever it is, you should use its IP address or FDQN (Fully Qualified Domain Name). That is, its full host name, including its domain names and a dot (.) in the end of the name, like headnode.clus-lab.austin.ibm.com.

Example B-2 contains an example of the zone files that we used in our lab environment.

Starting the DNS server

Once your DNS zone files are created, you can start the DNS server and set it to be startable at boot time:

 [root@master /root]# /etc/rc.d/init.d/named start Starting named:                                            [ OK ] [root@master /root]# chkconfig named on

You can verify that no errors occurred by inspecting the file /var/log/messages:

 # tail -f /var/log/message Nov 29 19:58:43 master named: named startup succeeded Nov 29 19:58:43 master named[7620]: starting BIND 9.1.0 -u named Nov 29 19:58:43 master named[7620]: using 1 CPU Nov 29 19:58:43 master named[7624]: loading configuration from '/etc/named.conf' Nov 29 19:58:43 master named[7624]: the default for the 'auth-nxdomain' option is now 'no' Nov 29 19:58:43 master named[7624]: no IPv6 interfaces found Nov 29 19:58:43 master named[7624]: listening on IPv4 interface lo, 127.0.0.1#53 Nov 29 19:58:43 master named[7624]: listening on IPv4 interface eth0, 192.168.1.100#53 Nov 29 19:58:43 master named[7624]: dns_master_load: csm-labs.austin.ibm.com.zone:29: ignoring out-of-zone data Nov 29 19:58:43 master named[7624]: running

A mistake in the configuration file or zone files will prevent named from loading the file and that may be not easy to track. In that case, you may start the daemon using the -d # option (debug), where # is the debug level. When run with this option, named will create a debug file named named.run in the current directory with the required debug level.

Testing the DNS server

The best way to test a name server is to use programs like dig, nslookup, or host.

dig

The syntax of this command is:

 dig @server domain query-type query-class

For example:

 [root@master /root]# dig @localhost clus-lab.austin.ibm.com ns ; <<>> DiG 9.1.0 <<>> @localhost clus-lab.austin.ibm.com ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7457 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;clus-lab.austin.ibm.com.       IN      NS ;; ANSWER SECTION: clus-lab.austin.ibm.com. 86400  IN      NS 192.168.1.100.clus-lab.austin.ib m.com. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Wed Dec 5 23:42:55 2001 ;; MSG SIZE rcvd: 69 [root@master /root]# [root@master /root]# dig @localhost . ns ; <<>> DiG 9.1.0 <<>> @localhost . ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7780 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;.                              IN      NS ;; ANSWER SECTION: .                       191030  IN      NS      M.ROOT-SERVERS.NET. .                       191030  IN      NS      A.ROOT-SERVERS.NET. .                       191030  IN      NS      B.ROOT-SERVERS.NET. .                       191030  IN      NS      C.ROOT-SERVERS.NET. .                       191030  IN      NS      D.ROOT-SERVERS.NET. .                       191030  IN      NS      E.ROOT-SERVERS.NET. .                       191030  IN      NS      F.ROOT-SERVERS.NET. .                       191030  IN      NS      G.ROOT-SERVERS.NET. .                       191030  IN      NS      H.ROOT-SERVERS.NET. .                       191030  IN      NS      I.ROOT-SERVERS.NET. .                       191030  IN      NS      J.ROOT-SERVERS.NET. .                       191030  IN      NS      K.ROOT-SERVERS.NET. .                       191030  IN      NS      L.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET.     364083  IN      A       198.41.0.4 B.ROOT-SERVERS.NET.     364083  IN      A       128.9.0.107 C.ROOT-SERVERS.NET.     364083  IN      A       192.33.4.12 D.ROOT-SERVERS.NET.     364083  IN      A       128.8.10.90 E.ROOT-SERVERS.NET.     364083  IN      A       192.203.230.10 F.ROOT-SERVERS.NET.     364083  IN      A       192.5.5.241 G.ROOT-SERVERS.NET.     364083  IN      A       192.112.36.4 H.ROOT-SERVERS.NET.     364083  IN      A       128.63.2.53 I.ROOT-SERVERS.NET.     364083  IN      A       192.36.148.17 J.ROOT-SERVERS.NET.     364083  IN      A       198.41.0.10 K.ROOT-SERVERS.NET.     364083  IN      A       193.0.14.129 L.ROOT-SERVERS.NET.     364083  IN      A       198.32.64.12 M.ROOT-SERVERS.NET.     364083  IN      A       202.12.27.33 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Wed Dec  5 23:43:21 2001 ;; MSG SIZE  rcvd: 436 [root@master /root]#

nslookup

An example of nslookup follows:

 [root@master named]# nslookup -sil > clsnode1 Server:         192.168.1.100 Address:        192.168.1.100#53 Name:   clsnode1.csm-labs.austin.ibm.com Address: 192.168.1.201 > ftp Server:         192.168.1.100 Address:        192.168.1.100#53 ftp.csm-labs.austin.ibm.com     canonical name = master.csm-labs.austin.ibm.com. Name:   master.csm-labs.austin.ibm.com Address: 192.168.1.100 > 192.168.1.202 Server:         192.168.1.100 Address:        192.168.1.100#53 202.1.168.192.in-addr.arpa      name = clsnode2.csm-labs.austin.ibm.com.

host

An example of host follows:

 [root@master named]# host master master.csm-labs.austin.ibm.com. has address 192.168.1.100 [root@master named]# host mail mail.csm-labs.austin.ibm.com. is an alias for master.csm-labs.austin.ibm.com. master.csm-labs.austin.ibm.com. has address 192.168.1.100 [root@master named]#

Note

The second example of dig gets all the name server (NS) records for domain . (dot). This domain (.) is the root domain of the entire DNS infrastructure, and those are the servers that are constantly asked about .com, .edu, .us, .fr, .br, and all top level domains. The output of this example is exactly the root.db or cache.db file defined in /etc/named.conf, defining the root servers for DNS. These entries do not change very often, but it is very common to add entries in the crontabs file of DNS servers to update their DNS root servers from time to time, by issuing the exact command used in the example and directing its output to the root.db file. But because the DNS server used in our examples does have forward servers, it will not do resolution using the root servers, and its configuration in /var/named.conf does not have an entry for the zone.

BIND logging

BIND is able to create detailed logging about its use, queries, security problems, violation attempts, and many other things. A simple logging configuration that would split its records in four different files in /var/log/bind can be found in Example B-3. This sample configuration should be placed in the /etc/named.conf file in the main section. Basically, it creates four different logging channels (config, critic, secure, and other), one for each log file, and then attaches DNS events to one of the logging channels. Some events are also being directed to the preexisting channel null.

Example B-3: BIND logging example

 logging {         channel config {                 file "/var/log/bind/config";                 severity debug;                 print-category yes;                 print-severity yes;                 print-time yes;         };         channel critic {                 file "/var/log/bind/critic";                 severity debug;                 print-category yes;                 print-severity yes;                 print-time yes;         };         channel secure {                 file "/var/log/bind/secure";                 severity debug;                 print-category yes;                 print-severity yes;                 print-time yes;         }; channel other {                 file "/var/log/bind/other";                 severity debug;                 print-category yes;                 print-severity yes;                 print-time yes;         };         category config { config; };         category security { secure; };         category xfer-in { other; };         category xfer-out { other; };         category update { other; };         // Don't want these messages         category lame-servers { null; };         category notify { null; };         category queries { null; }; };

Other features

BIND has many other features that may be useful in cluster environments, but that are not covered in this redbook. If you need more information, we suggest you reference the Linux Documentation Project Web site at:

http://www.linuxdoc.org

< Day Day Up >