Debian Clusters for Education and Research: The Missing Manual

Forward DNS - Name to IP Address (db.yourdomain)

From Debian Clusters

Jump to: navigation, search

This is the third page of a five part tutorial on setting up Name Service: DNS and BIND. The full tutorial includes

/etc/bind/db.yourdomain

/etc/bind/db.yourdomain is the file responsible for resolving a host's IP address from its domain name. This is the db.yourdomain file we referred to in the /etc/bind/named.conf.local file in the last section. It needs to be manually created.

Time to Live

The first line in this file should specify the TTL (the time to live) for this zone. This is how the nameserver runs before it rechecks the local files to see if any changes have been made. It is specified with $TTL and then the time. The default value, without any units, is in seconds, but minutes and hours can be specified with m and h respectively, like this:

$TTL 24h

Start of Authority Record

The next line needs to be the start of authority (SOA) line. The format of this record is very specific, as shown below.

<domain name>.  IN  SOA  <primary nameserver>. <email address of admin>. (
                    <serial number>
                    <time to refresh>
                    <time to retry>
                    <time to expire>
                    <negative caching ttl>
)
  • domain name - The domain name needs to be specified followed immediately by a period.
  • IN and SOA refer to this being an Internet and start of authority record.
  • primary nameserver - This is domain name of the server you're currently setting up to be the master nameserver.
  • email address of admin - This field is meant be helpful for people rather than the computers. It is the e-mail address for people to contact if they have problems with the domain. Of course, it's less important on an internal network on a cluster. Something like root@yourdomain should be fine. Replace any @ characters with periods.


The rest of the fields here are much more important when running multiple nameservers, one as the master and one or more as slaves that draw their information from the master. It isn't a bad idea to have a backup DNS server running in case the first one goes down.

  • The serial number can be any whole number, as long as it increments as this file changes. The serial number is what slave nameservers use to determine whether any changes have occurred since the last time they contacted the master nameserver. A common convention is to use the date, yyyymmdd, with the number of changes that have occurred that day appended to it. Then it's easy for an administrator to tell if the serial number has been incremented when making changes.
  • refresh is the amount of time a slave nameserver runs before contacting the master nameserver to see if any changes have occurred in the zone data.
  • retry is the amount of time a slave nameserver waits before contacting the master nameserver again after having attempted to reach it once and failing.
  • expire is how long the slave nameserver will continue to run and provide data after having lost contact with the master nameserver.
  • negative caching ttl is the amount of time the slave nameserver will give "negative" information about a domain, saying that it doesn't exist or the type of data requested doesn't exist.


My file so far looks like this. Semi-colons are comments.

$TTL    24h

raptor.loc.   IN  SOA   eyrie.raptor.loc.   root.raptor.loc (
        2007062800 ; serial
        3h         ; refresh
        30m        ; retry
        7d         ; expire
        3h         ; negative caching ttl
)

Nameserver Records

Although we've already specified the primary nameserver above in the SOA record, we need to specify any nameservers here, with the format

<domain name>. IN NS <nameserver1>.
<domain name>. IN NS <nameserver2>.

and so forth. NS here stands for Name Server. They can be specified by domain name or by IP address, but specifying it by IP address (you guessed it) takes out a potential point of failure. Make sure to specify the master name server here, as well as any slaves.

I only have my single nameserver and no slaves:

raptor.loc. IN NS 192.168.1.254.

Address Records

Address (A) records are where we finally get to specify the domain names for each of the machines. Here, the format is

<full domain name>. IN A <IP address>

Make sure to specify each of the machines on the internal network. The IP addresses here need to match those specified with the DHCP server. Notice mine follow the layout in my game plan from the Network Topology. Here's my full db.raptor.loc file. Semicolons are comments.

$TTL    24h

raptor.loc.   IN  SOA   eyrie.raptor.loc.   root.raptor.loc (
        2007062800 ; serial number
        3h         ; refresh time
        30m        ; retry time
        7d         ; expire time
        3h         ; negative caching ttl
)

; Nameservers
raptor.loc.  IN  NS  192.168.1.254.

; Hosts
eyrie.raptor.loc.       IN  A   192.168.1.254
gyrfalcon.raptor.loc.   IN  A   192.168.1.200
kestrel.raptor.loc.     IN  A   192.168.1.201
owl.raptor.loc.         IN  A   192.168.1.202
goshawk.raptor.loc.     IN  A   192.168.1.203
osprey.raptor.loc.      IN  A   192.168.1.204
peregrine.raptor.loc.   IN  A   192.168.1.205
kite.raptor.loc.        IN  A   192.168.1.206
eagle.raptor.loc.       IN  A   192.168.1.207
harrier.raptor.loc.     IN  A   192.168.1.208

Restarting Bind

Bind can be restarted at this time

/etc/init.d/bind9 restart

and it should successfully reload. It will complain about its missing file(s), though.

eyrie:/etc/bind# /etc/init.d/bind9 restart
Stopping domain name service...: bind.
Starting domain name service...: bind.
eyrie:/etc/bind# tail /var/log/syslog
Jul  3 19:22:42 eyrie named[2847]: command channel listening on ::1#953
Jul  3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file /etc/bind/db.1.168.192 failed: file not found

Continue on to the next section, Reverse DNS - IP Address to Name (db.yourIPreversed), to fix this problem.

Personal tools