Setting Up a Nameserver
A nameserver is a server that resolves hostnames to IP addresses. Instead of having
to
type in "209.81.10.250", I can just type in "www.computing.com" to get
to a
site. BIND is nameserver software that runs on many types of machines, originally
written by Paul Vixie and now maintained by the Internet Software Consortium (ISC).
This was one of the trickiest things I've had to try to figure out so far. I didn't
talk
to anybody as to how to go about this, unlike PPP setup. But I finally found the
Linux DNS HOWTO and used that. Hopefully this will save you some trouble. Here
I
have instructions for BIND 8, which is newer and more advanced than BIND 4 (which
some distributions still use).
Removing Old Nameserver (BIND 4)
Installing New Nameserver (BIND 8)
Configuration: /etc/named.conf
Caching Nameserver
Zone Files in /var/named
Examples of Zone Files
Domains
Localhost
Reverse Mapping
Resources
Removing Old Nameserver (BIND 4)
In the event that your distribution already comes with BIND 8, then all you
need to do
is find out how the configuration works, and/or put in entries for machines
that the
Linux box will be the nameserver for. I think Slackware comes with BIND 8. I
don't
know about Debian. Most new distributions (including Red Hat 5.2) will already
have
BIND 8 so you'll probably have to look for the configuration file and how it
has
been pre-configured.
I had to remove the old nameserver first, so it wouldn't
get in the way of the new one.
It's fine to remove it and replace it with a new one; there aren't any other
packages that really depend on it.
Using Red Hat 5.1, I typed rpm -e bind bind-utils caching-nameserver. That removed
all
the old packages. Be careful about this, especially about bind-utils, because
bind-utils contains the tools such as dnsquery and nslookup that you might be
using
fairly often. Red Hat 5.2 already has BIND 8.
Installing New Nameserver (BIND 8)
First, download BIND from ftp://ftp.isc.org/. If you've got it on your system
already,
then you don't need to get BIND 8 unless you want to make a minor upgrade. The
filename is something like bind-8.1.2-src.tar.gz, which says that it's BIND
version
8.1.2 in source format (which you have to compile on your system). I'll work
with
the source version since that's what I usually do anyway.
After you have it on your system, type tar -zxvf bind-8.1.2.tar.gz. It will
extract a
directory called src/ and that's where you go into. Simply type "make" and have
it
compiled for you. If you need anything to be tweaked then read the INSTALL file
(less INSTALL) and find what you need. After it finishes compiling, type make
install.
Configuration: /etc/named.conf
Configuring the nameserver was probably the hardest part of the process that I
had to go
through. Hopefully, what I've written up about what I learned will save the reader
some trouble.
The main BIND 8 configuration file is in /etc/named.conf. The configuration syntax
for
the file is documented at http://www.isc.org/bind8/config.html. Here's a sample
of a
configuration file (as /etc/named.conf), with an explanation below.
/*
* A simple BIND 8 configuration
*/
options {
directory "/var/named";
};
zone "computing.com" in {
type master;
file "master/computing.com";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "zone/127.0.0";
};
zone "." in {
type hint;
file "named.cache";
};
In "options" I only had one option: where the directory for zone files were. Zone
files
are where information about domains is stored, and each file has information about
a
zone. It's a section to cover, I guess, so that's why they're called zones. I
have
/var/named/ as my named data directory.
The "computing.com" section is pretty straightforward. It just indicates
the
location of the computing.com zone files and tells named that this server
is
a master nameserver for the computing.com zone.
The "0.0.127.in-addr.arpa" zone is for mapping localhost to 127.0.0.1, basically.
It has
its own zone file.
The "." zone indicates a caching nameserver; that is, someone can actually use
your
machine to resolve hostnames (including you). I've heard that is is efficient
especially when using PPP connections, but I don't know for sure. Read the "Caching
Nameserver" section to read up on how to create one.
Caching Nameserver
First you need to get a "named.cache" file. I'm not sure if you can name it anything
else, but let's just use that filename. In /var/named/ (or wherever you put your
nameserver's data files), type dig @a.root-servers.net > named.cache. This will
ask
for the addresses of the main DNS servers of the Internet and direct them to a
file.
I'm guessing that the purpose of this is to give your machine an idea of which
machines on the Internet to ask about hosts.
Periodically, like once a month, update the named.cache file by running that command
once in a while. You can use a cron job for that. If you don't know what I'm talking
about here, don't worry about it. Just be sure to update it using dig once in
a
while, that's all you have to do.
You have /etc/named.conf point to wherever your named.cache file is under the
"." zone.
Zone Files in /var/named/
In /var/named/, I created directories for every type of zone I had. The directories
I
have in there are: master, slave/, and zone. With the domain name system, there
is a
server for each domain that is the main server (the master). I suppose that the
slave server is there in case the main (master) server is down. For each domain
there should be at least 2 servers, one master and one slave. That's just the
way it
goes.
While interning at Penguin Computing I set up both the master and slave DNS servers.
The
master's information should go in the master directory. You should be able to
figure
out where the slave's information goes. The information they store is the same,
but
since one machine is the main one that keeps the information (master) and the
other
simply follows the master's information (slave), you need to stay organized and
make
sure you're configuring the right machine for its right place in the nameserver
system.
Note that the slave nameserver for one domain can also be the master nameserver
for
another domain. There just can't be two masters for a single domain, though I
think
there can be several slaves.
Examples of Zone Files
To figure something like this out, I was looking hard for examples. And examples
really
help, so hopefully you won't be too confused by my examples. Hey, I try.
Domains
The information for each domain is put in a single file. This file contains valuable
information for each domain, such as machines that are under that domain (like,
for
the computing.com domain, the nameservers would have the information for
what
IP address pasta.computing.com gets and the one that
antarctica.computing.com gets). Here's an example of a domain's records:
@ IN SOA computing.com. root.computing.com.
(
1998082403 ; serial
4H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
NS pasta.computing.com.
NS rice.computing.com.
MX 10 computing.com. ; Primary Mail Exchanger
localhost A 127.0.0.1
router A 140.174.204.2
computing.com. A 209.81.10.250
ns A 209.81.10.250
www A 209.81.10.250
ftp CNAME computing.com.
mail CNAME computing.com.
news CNAME computing.com.
pasta CNAME computing.com.
slashdot CNAME computing.com.
rice CNAME antarctica.computing.com.
antarctica A 209.81.10.252
antarctic CNAME antarctica.computing.com.
www.antarctic CNAME antarctica.computing.com.
www.antarctica CNAME antarctica.computing.com.
zork A 209.81.10.253
tux A 209.81.10.146
xfce A 209.81.10.252
@ TXT "Penguin Computing"
@ HINFO Linux 2.0.34
There's a pretty weird syntax to be used for these zone files. I never would have
figured it out on my own had I not read the Linux DNS HOWTO document. Basically,
it
specifies information about all the machines in the domain, and it contains
information about the domain itself, such as the type of machine the server is
running on.
I'll start explaining what all the stuff does. In the
first line, it's saying that this
file specifies the zones for the computing.com domain, and to send anything
about the domain to root@computing.com. Since the "@" character has special
significance in these zone files, the username (root) and machine name
(computing.com) have to be separated by a dot. I guess BIND just knows
how to
split it up. That's how you fill in stuff for your domain as well.
The line with the comment "serial" shows the serial number of that domain. The
syntax is
YYYYMMDDRR; that is, a four digit year, two digit month in numerical form, two
digit
day format, and a two digit revision number. In this example (1998082403), it
shows
that the zone file was last modified on August 24, 1998. It's the third revision
for
that day. When you're changing anything in the file, make sure to increase the
revision number by one if the previous change was on the same day. If I were
to
change the IP of one of the hosts, I would make the last two numbers, currently
03,
to 04.
The next few lines show times for certain functions such as refreshing, retrying,
and
expiring the information. I'm not absolutely sure, but my best guess is that
H
stands for hour, D stands for day, and W stands for week.
The "NS" line indicates all the nameservers for that particular domain, including
the
one this information is on. This information has to match what has been registered
with InterNIC. For the hostnames of the nameservers, remember to add a dot at
the
end. If you don't, it will add the hostname to the current domain. For example,
if
you forgot the dot at the end of pasta.computing.com, you would end up
with
the nameserver being pasta.computing.com.computing.com, which
is
obviously not what it's supposed to be. Watch out for this.
The MX file is the Mail eXchange record, so that mail can get through to the
domain.
There should also be an entry in /etc/sendmail.cw to allow messages coming in
from
that domain (assuming you're using Sendmail, the default on many Linux systems,
for
mail transfer).
The next couple of lines point to the local loopback (127.0.0.1), which all
Linux
systems should have even if they aren't connected to a network. The "router"
line
points to the IP address of where the machine's Internet connection is. I'm
not sure
if it's really necessary but I was playing it safe back then and trying to copy
the
example from the DNS HOWTO as closely as possible.
The rest of the entries use either A (address) or CNAME (Canonical Name) to
point
hostnames to IP addresses. Note that hostnames can be mapped to other hostnames,
or
they can be mapped to IP addresses. Use A to map a name to an IP address, and
CNAME
to map a hostname to another hostname (which must be mapped to another IP address).
Localhost
The file for mapping localhost is pretty simple. Not much explanation needed.
Of course,
if you want to copy and paste, be sure you make the proper changes.
@ IN SOA computing.com root.computing.com (
1998072401 ; Serial number
3H ; Refresh
1H ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS pasta.computing.com.
NS rice.computing.com.
1 PTR localhost.
Reverse Mapping
This file looks similar to the zone file for the domains, but it provides the
opposite
function. It points IP addresses to hostnames (as opposed to vice versa), because
many servers on the Internet do this thing called reverse lookup on the IP address
of your hostname to make sure that you're not doing anything sneaky.
This is for the zone "209.81.10" specified in the sample configuration file.
Note that
my example is not complete, nor does it work in reality, because Penguin Computing
doesn't own the whole block of "209.81.10.*". But this is how you'd fill in
a file
to resolve your IP addresses to hostnames if you owned the entire block of IP
addresses.
@ IN SOA computing.com. root.computing.com. (
1998072002 ; Serial
4H ; Refresh
2H ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS pasta.computing.com.
NS rice.computing.com.
;
; Servers
;
250 PTR pasta.computing.com.
250 PTR computing.com.
250 PTR ftp.computing.com.
250 PTR www.computing.com.
250 PTR mail.computing.com.
251 PTR rice.computing.com.
;
; Workstations
;
252 PTR antarctica.computing.com.
252 PTR antarctic.computing.com.
If you were to fill in an actual zone file like this, it's necessary to fill
in all the
entries in your block of IP addresses, from 1 to 255. For something like that
you
may want to assign the task to anyone who looks bored.
So what should you do if you only own a domain but not the block of IP addresses
that
it's part of? Ask the people who are in charge of that block of IP addresses
to map
your IP addresses to their respective hostnames for you.
More on http://linuxperf.nl.linux.org/
|