Translations by Andres Rodriguez

Regenerate the SSL certificate if our application can be accessed through SSL.

There a many ways to configure <application>BIND9</application>. Some of the most common configurations are a caching nameserver, primary master, and a as a secondary master.

As a primary master server BIND9 reads the data for a zone from a file on it's host and is authoritative for that zone.

In a secondary master configuration BIND9 gets the zone data from another nameserver authoritative for the zone.

The DNS configuration files are stored in the <filename>/etc/bind</filename> directory. The primary configuration file is <filename>/etc/bind/named.conf</filename>.

The <emphasis>include</emphasis> line specifies the filename which contains the DNS options. The <emphasis>directory</emphasis> line in the <filename>/etc/bind/named.conf.options</filename> file tells DNS where to look for files. All files BIND uses will be relative to this directory.

Caching Nameserver

The default configuration is setup to act as a caching server. All that is required is simply adding the IP Addresses of your ISP's DNS servers. Simply uncomment and edit the following in <filename>/etc/bind/named.conf.options</filename>:

To add a DNS zone to BIND9, turning BIND9 into a Primary Master server, the first step is to edit <filename>/etc/bind/named.conf.local</filename>:

Now use an existing zone file as a template to create the <filename>/etc/bind/db.example.com</filename> file:

Also, create an <emphasis>A record</emphasis> for <emphasis role="italic">ns.example.com</emphasis>. The name server in this example:

You must increment the <emphasis>Serial Number</emphasis> every time you make changes to the zone file. If you make multiple changes before restarting BIND9, simply increment the Serial once.

Now, you can add DNS records to the bottom of the zone file. See <xref linkend="dns-record-types"/> for details.

Many admins like to use the last date edited as the serial of a zone, such as <emphasis>2007010100</emphasis> which is yyyymmddss (where <emphasis>ss</emphasis> is the Serial Number)

Once you have made a change to the zone file <application>BIND9</application> will need to be restarted for the changes to take affect:

Reverse Zone File

Replace <emphasis>1.168.192</emphasis> with the first three octets of whatever network you are using. Also, name the zone file <filename>/etc/bind/db.192</filename> appropriately. It should match the first octet of your network.

Next edit <filename>/etc/bind/db.192</filename> changing the basically the same options as <filename>/etc/bind/db.example.com</filename>:

After creating the reverse zone file restart <application>BIND9</application>:

Once a <emphasis>Primary Master</emphasis> has been configured a <emphasis>Secondary Master</emphasis> is needed in order to maintain the availability of the domain should the Primary become unavailable.

Replace <emphasis>192.168.1.10</emphasis> with the IP Address of your Primary nameserver.

Restart <application>BIND9</application> on the Secondary Master:

In <filename>/var/log/syslog</filename> you should see something similar to:

This section covers ways to help determine the cause when problems happen with DNS and <application>BIND9</application>.

You should also add the IP Address of the Secondary nameserver in case the Primary becomes unavailable.

ping example.com

named-checkzone

Finally, you should restart the <application>PostgreSQL</application> service to initialize the new configuration. From a terminal prompt enter the following to restart <application>PostgreSQL</application>:

The following sections discuss various ways of accomplishing these tasks.

Shell Scripts

Simple Shell Script

<emphasis>c:</emphasis> creates an archive.

<emphasis>z:</emphasis> filter the archive through the <application>gzip</application> utility compressing the archive.

Executing the Script

The simplest way of executing the above backup script is to copy and paste the contents into a file. <filename>backup.sh</filename> for example. Then from a terminal prompt:

This is a great way to test the script to make sure everything works as expected.

The <application>cron</application> utility can be used to automate the script execution. The <application>cron</application> daemon allows the execution of scripts, or commands, at a specified time and date.

The <application>backup.sh</application> script will need to be copied to the <filename>/usr/local/bin/</filename> directory in order for this entry to execute properly. The script can reside anywhere on the file system simply change the script path appropriately.

Another option is to copy the archive file to an external hard drive which can then be taken off site. Since the price of external hard drives continue to decrease it may be cost affective to use two drives for each archive level. This would allow you to have one external drive attached to the backup server and one in another location.

A tape drive attached to the server can be used instead of a NFS share. Using a tape drive simplifies archive rotation, and taking the media off site as well.

Here is the shell script modified to use a tape drive: