Forward DNS - Name to IP Address (db.yourdomain)
From Debian Clusters
This is the third page of a five part tutorial on setting up Name Service: DNS and BIND. The full tutorial includes
- Name Service: DNS and BIND
- Installing and Configuring BIND
- Creating Forward DNS Records
- Creating Reverse DNS Records
- Testing and Troubleshooting BIND
/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. -
INandSOArefer 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 numbercan 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. -
refreshis the amount of time a slave nameserver runs before contacting the master nameserver to see if any changes have occurred in the zone data. -
retryis the amount of time a slave nameserver waits before contacting the master nameserver again after having attempted to reach it once and failing. -
expireis how long the slave nameserver will continue to run and provide data after having lost contact with the master nameserver. -
negative caching ttlis 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.

