Traditional DNS Howto

Version 1.0
Authors: Tom Adelstein <tom [dot] adelstein [at] gmail [dot] com>
Falko Timme <ft [at] falkotimme [dot] com>
Last edited: 03/11/2006

Linux system administrators should learn traditional DNS. Front-ends and quick
templates to setup domain records have a place in managing sites. When
confronted with DNS configurations already in existence, nothing can substitute
for knowing and using the fundamentals.
The vast majority of users on the Internet have no clue about DNS. They may
have seen the term when they set up their ISP connection, but they do not
realize its connection to their lives. Simply put, DNS servers allow you to use
friendly names in your browser, email or other Internet applications to perform
tasks which require IP addresses.
The Internet uses TCP/IP protocol to send and receive everything on the Internet.
When you type Google.com in your browser to do a search, you use DNS.
Otherwise, you would have to use this numeric value: 64.233.187.99. Click on
each one and see what you get.
You see Google.com is an name in a database that your browser consults to find
the IP address of the Google web site. But that's transparent to the user. How
would you like to keep a notebook of IP addresses to manually look up and find
web sites you wish to visit? Well, the Domain Name System does that for you
automatically.
If you're sitting there reading this and going, "Oh yeah, I already know about
that", then hold on a minute or two. Working with DNS requires considerable
knowledge and discipline. The system administrators I know can do many tasks,
yet few can handle DNS. Almost without exception, they get lost because they
don't understand the fundamentals.
The Domain Name System of the Internet makes up the largest distributed
database on the planet and it's quite ingenious. In theory, it has no flaws. In
practice, people kludge it up all the time. People make DNS entries in their part
of the database that aren't formatted correctly or have inherent deficiencies
which result in errors.
Internet surveys of DNS records have shown incidents of errors as high as 72%.
We know the majority of those errors come from lame delegations. Lame
delegations include domains registered with DNS servers assigned to them when
no one is actually hosting the domain. Other causes include the failure to provide
zone files, errors in resource records, expired domain registrations.
If you attempt to learn DNS jargon, you will find that it is not intuitive. At first it
just doesn't make sense. In many ways, the jargon reminds me of a foreign
language. You just have to work with it for a period of time before it makes
sense.
Linux uses BIND to perform DNS functions. Rather than attempt to use another
program, system administrators should start with BIND because it runs almost all
the DNS servers in the world. I'm not going to offer a history lesson on BIND
because this subject will put you to sleep anyway.
So, if you want to go forth and learn all about BIND please do. It won't help you
do much DNS with one exception. Some people still use BIND version 4. You want
to upgrade from BIND 4 to BIND 8 or 9. It's just my luck that you'll go out to
create DNS configuration files and they won't make any sense. That's because a
lot of people still run BIND 4.

Tell Me About Configuration Files

BIND comes with three components. The first components we called named or
name-dee. It's a daemon that runs the server side of DNS. That will make sense
in a little while.
The second component of BIND we call the resolver library. People think of a
resolver as the client side of BIND. The resolver code makes queries of DNS
servers in an attempt to translate a friendly name to an IP address. This
component uses the resolv.conf file. Does that sound like a UNIX abbreviation. It
should because it is.
The third component of BIND provides tools for testing you DNS server. We call
them tools but they are really a set of command line utilities like dig. Go to your
console and type dig yahoo.com and see what happens. We will look at this later.

What's My Responsibility In The DNS System?

As stated earlier, DNS is a distributed data base. When you pay a fee to register a
domain one of the questions you answer deals with your Name Servers. You have
to list two and they have to be registered in the DNS system.
The domain name system database has three levels. The first group of servers we
call "root" servers. The second we call Top Level Domains or (TLDs). When your
resolver needs to find the address for a web site, it makes a query.
Let's say you want to find Google.com. Your resolver asks the Root servers to
identify Google.com's IP. The Root server replies, I don't know but I do now
where you can find the answer. Start with the TLD servers for COM.
So, Root sends your query to a COM server. It says, OK. I don't have that
information but I know a Name Server that does. It has an address of
64.233.167.99 and the name ns1.google.com. So, go to that address and it will
tell you the web site address of google.com
Your resolver takes the information from ns1.google.com and returns with an IP
address. If Google's name server gave your resolver the correct name, you'll get
a web page.
The path traveled looks like Figure 1.
Figure 1 - From Root to your Domain.
In the upper left of Figure 1, we have depicted a set of servers with the
annotation of Root. In the jargon of DNS, these servers represent the beginning
of the DNS path. You will see them represented by a period or dot ("."). In your
configuration files, your IP address to name mapping will end with a period. When
we look at some of those files in a few minutes this will become clearer.
The Root servers are the top of the distributed DNS database. They have
information about the Top Level Domains(TLDs). TLDs include com, net, org,
mil, gov, edu, etc. When you contract to use a domain name, you chose which
TLD you want. In my case, I have a domain in the org name space called
centralsoft.org.
When I registered my name servers, I gave the name of
server1.centralsoft.org and ns0.centralsoft.org to my registration agent.
In the TLD servers for org, you will find my name servers. The org servers know
where you should find information on centralsoft.
When I registered, I told the agent that I would take responsibility for
maintaining a database of IP addresses and friendly names and map them to one
another. So, we made an agreement and the Domain Name System said, "OK,
now you have authority for the data on centralsoft.org. When someone wants to
find the services you offer on the Internet, we will point them to you."
So, now I have to run an application which can answer your queries and say,
"sure if you want to see my web page or send mail to one of my users, you can
find them here. If you ask me for a name, I'll give you an IP address because I
know you have this protocol which uses TCP/IP and I realize you need the
address, even when you specify a name".
How Do I Answer These Queries Now?
That's where BIND comes into play. The people who maintain the BIND code
make sure it meets the specifications of the Internet Engineering Task Force and
will run on your server. All you have to do is learn how it does what it does.
Named lives on a domain name server and answers queries from resolvers. The
application reads its data from a configuration file called named.conf. named.conf
gets its information from something we call zone files. Several zone files exist,
but one zone file in particular keeps a database of records that supply named with
most of its answers.
In Figure 2, named had received a query. It looks to its configuration file
named.conf, which looks to the primary zone file and hands off the information
requested to the resolver from the outside.

Figure 2 - Answering a query

Some people refer to configuration files as rule files. BIND's configuration files
seem like rule files to me. The rules of Domain Name Services require tight
compliance. Making and resolving queries follow strict protocols on the Internet
as does the interprocess communication within BIND.

Using Named.conf
Let's refer to Figure 2 again and look at the process. You should have BIND
installed and running on your server. If not, we will address installation and
configuration in one of the next sections.
The named process listens on port 53 of a Linux system. When it receives a query
for an address, it looks to the first configuration file about which it knows:
named.conf.

Figure 3 - named.conf
The following table depicts a simple named.conf file. If you have seen a file like
this and didn't understand it, then let's break it down into its components. Once
we do that, we can take the mystery out of it.
options {
pid-file "/var/run/bind/run/named.pid";
directory "/etc/bind";
// query-source address * port 53; };
//
// a master nameserver config
//
zone "." {
type hint;
file "db.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.local";
};
zone "158.253.70.in-addr.arpa" {
type master;
file "pri.158.253.70.in-addr.arpa";
};
zone "centralsoft.org" {
type master;
file "pri.centralsoft.org";
};
This file refers to the four other configuration files. The third line down lists the
directory containing them all, /etc/bind where they exist.
The options statement defines the default directory for named and the location
of the process ID (pid) file. named.pid represents the daemon itself. If you
followed any of the Perfect Setup Tutorials, we put it in a chrooted environment.
The zone statement identifies the location of the hints, localhost, zone and
reverse zone files.
● Hints file
This file contains the names and addresses of the root servers on the
Internet. These know where the authoritative servers for your domain
exist - the first one being the Top Level Domain (com, net, org, etc.) and
next being the authoritative server for your domain.
● Local host file
Name servers are the masters of their own loopback domain (127.0.0.1).
The point of creating local zone files for each aspect of your of localhost is
to reduce traffic and allow the same software to work on your system as it
does on the network.
● Zone file
This file, also called the domain database, defines most of the information
needed to resolve queries about the domain you administer. It maps
names to IP addresses and provides information about the services offered
by your Internet computer including your web and ftp server, email,
telnet, name servers, etc.

The zone file uses several record types including the SOA or start of
authority; NS or name server; A or host name to address map; PTR or
pointer which maps addresses to names; MX or mail exchanger which
identifies the mail servers in the domain; and CNAME or canonical name
which defines an alias for a host name.
 Don't try to memorize or understand what these record types mean at this
point. Just realize that they exist and you will have ample opportunity to
use them.
● Reverse zone file
Another way to talk about zone files is to define them something that links
all the IP addresses in your domain to their corresponding server. The
reverse zone file maps IP addresses to host files. It's a mirror image of the
database file above. You can recognize a reverse zone file because it has
the extension of in-addr.arpa.

Figure 4 - Zone files

The Primary Zone File

Now let's look at the zone file for the centralsoft domain: pri.centralsoft.org:
@ IN SOA server1.centralsoft.org. root.localhost. (
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds
;
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;
;
MX 10 server1.centralsoft.org.;
;
centralsoft.org. A 70.253.158.42
www A 70.253.158.42
server1 A 70.253.158.42
ns0 A 70.253.158.45
SOA refers to "Start of Authority". When you look at Figure 1, remember that DNS
distributes its database. By the time you enter the picture, the system has
handed off authority for part of the entire database to you. So, your zone file has
to indicate where your authority starts. Your authority starts in your zone file.
Your Top Level Domain servers are waiting for you to do your part of the job.
The data field of the SOA record contains several components or fields. You need
to provide data or answers in the record which will allow another server on the
Internet to satisfy its query. Think of the data field as a computer RECORD which
has several fields. They include:
● Name

The root name of the zone. The "@" sign is a shorthand reference to the
current origin (zone) in the /etc/named.conf file for that particular
database file. The host name of the master server for this zone is
server1.centralsoft.org. Don't worry if this jargon doesn't make sense. If
just means that back in the named.conf configuration file an entry points
to this file and this file points back to the entry in the configuration file.
● Class
 A number of different DNS classes exist. For our purposes we will use the
IN or Internet class used when defining IP address mapping information
for BIND. The other classes exist for non Internet protocols and functions.
● Type

The type of DNS resource record. In the example, this is an SOA resource
record.
● Name-server

Fully qualified name of your primary name server. Must be followed by a

period.
● Email-address

This is the email address of the person responsible for the domain. Notice
that instead of an @ sign, the address uses a period and is followed by a
period. In this case, the email address is the root user or root.loalhost. In
other applications the email address would be root@localhost.
● Serial-no

A serial number for the current configuration is usually in a date format

YYYYMMDD with an incremented double digit number tagged to the end.
This allows you to do multiple edits each day with a serial number that
both increments and reflects the date on which the change was made. It's
a numeric value that the slave server can use to check whether the zone
file has been updated. The slave periodically checks the serial number to
see if it has changed. If it has, the slave will perform a zone transfer.
2006012103 is the serial number in the zone file above.
● Refresh

This field tells a slave DNS server how often it should check the master.
This field represents a length in seconds. Every refresh cycle, the slave
server checks to see whether it needs to perform a zone transfer. In this
file we use 28800 as the value.
● Retry

This field tells the slave how often it should try to connect to the master in
the event of a connection failure. The interval in our example is 7200.
● Expiry

Total amount of time a slave should retry to contact the master before
expiring the data it contains. Future references will be directed towards
the root servers. This is the expiration time, the length of time that the
slave server should continue to respond to queries even if it cannot update
the zone file. An expiration period exists under the theory that out of date
data is worse than no data at all. In our example we use 604800.
● Minimum-TTL

This is the default time to live (TTL) for this domain in seconds. Times will
occur when remote clients will make queries for sub-domains that don't
exist in your records. If so configured, your DNS server will respond with a
no domain or NXDOMAIN response that the client's remote server caches.
The TTL value defines the caching duration your DNS response. The value
is included in your server's response. Any resource record that does not
have a specified TTL uses this default. Because 86400 seconds is one day,
the querying cache's record should die in one day.
The next database record type specifies the name servers for the domain. NS
stands for name server. You already know that server1.centralsoft.org represents
the host name of the primary domain server. The secondary or slave server for
this domain follows. ns0.centralsoft.org is the hostname of the secondary name
server for this domain.
Following the name servers you will see the MX record type which identifies the
mail server for the domain. Following the mail record you can see the A record
type which maps a name to an IP address. In the file above we have four A
records which map the host names to IP addresses.
Let's write a zone file. You should name it for your own domain. Mine is
pri.centralsoft.org. Name your zone file for your domain.
The first line in our zone file looks like this:
@ IN SOA server1.centralsoft.org. root.localhost. (

The "@" sign in the line refers to the "origin" for this zone file which is
server1.centralsoft.org. DNS uses this as simply a label to designate the Start Of
Authority (SOA) record that appears at the beginning of any zone file defining a
domain. Don't make too much out of this. If you read much about DNS, then you
will see people using this strange term "current origin". Few people explain what
that means. It's just another bit of jargon.
The next item on the line "IN" stands for Internet. People call this a class field.
Three classes exist including "HS" for Hesiod servers and "CH" which stands for
Chaosnet servers. You will only see Internet servers, so don't sweat the small
stuff.
IETF RFC 1035, Domain Names - Implementation and Specification says:
The SOA record stores information about the name of the server that
supplied the data for the zone; the administrator of the zone; the
current version of the data file [serial number]; the number of
seconds a secondary name server should wait before checking for
updates; the number of seconds a secondary name server should wait
before retrying a failed zone transfer; the maximum number of
seconds that a secondary name server can use data before it must
either be refreshed or expire; and a default number of seconds for the
time-to-live file on resource records.

What's next? The mailing address of the administrator in this file is

root@localhost. Obviously, my mail server delivers local mail so messages related
to this process will go to root's mailbox.
In case you missed it, the first line is only part of the SOA record. It has
additional fields. Notice the "(" at the end of the line. Here's the rest of the
record.
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds

The serial number is the only field in the record that does not refer to seconds.
You designate the serial number as a numeric value so when a slave server
checks to the zone file on the primary server if will know if the zone file changed.
The slave can then do a zone transfer and populate its database with the current
records.
The remaining fields use seconds to denote their values. For example, the
number of seconds a secondary name server should wait before checking for
updates is in the refresh record. 28800 seconds is 480 minutes or 8 hours.
Also notice that the SOA record ends at the end of the Minimum-Time to Live
(TTL). You can see the ")" symbol which closes the record values.

NS Records

Next we create NS records. These specify the name servers that are responsible
for our domain. You must have at least one, however it is common practice to at
least list two (you can list as many as you want) - if the primary name server
fails, the secondary takes over:
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;
Please note: the semicolon (';') does not mark the end of a line; instead it
marks the beginning of a comment in a zone file. You can write
NS server1.centralsoft.org.; This is my primary name server.
However, if you do not have any comments, you can as well write
NS server1.centralsoft.org.

MX Records

As we want to receive emails on centralsoft.org, we must list the mail exchanger

(s) for the domain. This is done with an MX record:
MX 10 server1.centralsoft.org.
This record says that emails for centralsoft.org should be delivered to
server1.centralsoft.org (which is the mailserver for the domain) with a priority of
10. You can list more than one mail exchanger:
MX 10 server1.centralsoft.org.
MX 20 mail.someotherdomain.com.
Now if a mail is sent to centralsoft.org, the sending mailserver tries to connect to
server1.centralsoft.org because it has a priority of 10. If server1.centralsoft.org
cannot be reached (for whatever reason), then the sending mailserver will try to
send the mail to mail.someotherdomain.com because it has a priority of 20 which
comes next (you see: although 20 is greater than 10, it means less priority in this
case).
Until now we have defined MX records for centralsoft.org only which is good for
email addresses of the form user@centralsoft.org. Let's say we have an email
address of the form user@subdomain.centralsoft.org. Therefore we must create
an MX record for subdomain.centralsoft.org:
subdomain.centralsoft.org. MX 10 server1.centralsoft.org.
Please note the '.' at the end of subdomain.centralsoft.org. If you do not add it,
then the origin of the zone is appended to the name. For example, if you wrote
subdomain.centralsoft.org MX 10 server1.centralsoft.org.
without a '.', this would transfom to subdomain.centralsoft.org.centralsoft.org! Of
course, this feature can be useful:
subdomain MX 10 server1.centralsoft.org.
Now we only have subdomain, but because the '.' is missing at the end, it
transforms to subdomain.centralsoft.org which is what we want. So
subdomain.centralsoft.org. MX 10 server1.centralsoft.org.
or
subdomain MX 10 server1.centralsoft.org.

are two notations for the same thing!

A Records

Up to now we have used the domain names centralsoft.org,

server1.centralsoft.org, and ns0.centralsoft.org, but we did not specify anywhere
to which IP addresses these domains should point to. That's where A records
come into play. A records are the most important DNS records; with them you
can create host addresses. Let's create our first A record:
centralsoft.org. A 70.253.158.42
This means that centralsoft.org has the IP address 70.253.158.42. Remember my
hint about the '.'? You can also write
A 70.253.158.42
which means exactly the same.
Now in a browser you are used to typing www.centralsoft.org instead of
centralsoft.org, aren't you? www.centralsoft.org is technically totally different
from centralsoft.org, but obviously you expect to see the same web site for both.
Therefore we create this record:
www A 70.253.158.42
which is the same as
www.centralsoft.org. A 70.253.158.42
Finally we specify server1.centralsoft.org and ns0.centralsoft.org:
server1 A 70.253.158.42
ns0 A 70.253.158.45
ns0.centralsoft.org points to a different IP address which makes sense because it
is our secondary nameserver which should be on a different system in case our
primary nameserver goes down.

CNAME Records

CNAME is short for "canonical name", you can think of it as an alias to an A

record. For example,
ftp CNAME www
means, ftp.centralsoft.org is an alias for www.centralsoft.org, so
ftp.centralsoft.org points to the same machine as www.centralsoft.org.
A CNAME must always point to an A record; a CNAME must not point to another
CNAME! In addition to that, you must not use CNAME records for MX and SOA
records. For example,
MX 10 ftp
is not allowed!
The usage of CNAMEs has its pros and cons. I can hear you say "If the usage of
CNAME records has that many restrictions, why don't we always use A records?"
That's true, but imagine you have hundreds of machine names as A records,
pointing to the same IP address, and now you move the server to another data
center where it is assigned a different IP address. You'd have to update every
single A record. If you had just one A record and all other records were CNAMEs,
you'd just have to update one A record...

TXT Records

TXT records give you the ability to assign some text/additional information to a
zone. Normally this feature is not much in use - with one exception: SPF (Sender
Policy Framework) records. These are records that specify from which machines
you are allowed to send mail with the sender domain centralsoft.org. Technically,
you can send such mails from any machine, but big email providers such as
Yahoo or Hotmail now make heavy usage of SPF records, i.e.: if the sender
domain does not have an SPF record or is sending from a machine that is not
listed in the SPF record, then the mail is classified as spam.
There is a wizard for creating SPF records at
http://www.openspf.org/wizard.html?mydomain=&x=26&y=8. We use this
wizard to create an SPF record for centralsoft.org, and add this to our zone file:
centralsoft.org. TXT "v=spf1 a mx ~all"
server1.centralsoft.org. TXT "v=spf1 a -all"

Putting It All Together

Now we put all these records in our zone file pri.centralsoft.org. It looks like
this:
@ IN SOA server1.centralsoft.org. root.localhost. (
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds
;
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;
;
MX 10 server1.centralsoft.org.
;
centralsoft.org. A 70.253.158.42
www A 70.253.158.42
server1 A 70.253.158.42
ns0 A 70.253.158.45
ftp CNAME www
centralsoft.org. TXT "v=spf1 a mx ~all"
server1.centralsoft.org. TXT "v=spf1 a -all"

The Reverse Zone File

Now programs can look up the centralsoft.org domain and all its subdomains in
DNS, but now we need a reverse zone which maps IP addresses to
centralsoft.org. This reverse lookup is used by many programs that will refuse to
talk to you if the reverse lookup and the forward lookup (i.e. the normal lookup of
centralsoft.org) do not mtach each other. For example, many email providers use
reverse lookups to classify emails as spam or not spam.
Because we do not want emails originating from the centralsoft.org domain to be
classified as spam, we create a reverse zone.
Therefore we have this in our named.conf file:
zone "158.253.70.in-addr.arpa" {
type master;
file "pri.158.253.70.in-addr.arpa";
};
What are the numbers in there? As you noticed, centralsoft.org is in the
70.253.158.x net. Now we take this string 70.253.158 and write it the other way
round (158.253.70) and use it in the zone section we add to named.conf.
We also name our reverse zone file like this: pri.158.253.70.in-addr.arpa. We
create pri.158.253.70.in-addr.arpa in the same directory as our "forward"
zone file pri.centralsoft.org.
The beginning of pri.158.253.70.in-addr.arpa looks exactly like in
pri.centralsoft.org:
@ IN SOA server1.centralsoft.org. root.localhost. (
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds
;
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;
But now, we do not create A, MX, CNAme, etc. records anymore, we only create
PTR records.

PTR Records

PTR is short for pointer, and that's what it is: it points to a domain name. Let's
create a PTR record for centralsoft.org:
42 PTR centralsoft.org.
centralsoft.org's IP address is 70.253.158.42, and we want 70.253.158.42 to
point to centralsoft.org.
We create exactly one pointer for each IP address we use; the only other IP
address we use is 70.253.158.45 (for ns0.centralsoft.org), so we add:
45 PTR ns0.centralsoft.org.
That's all. Our reverse zone file looks now like this:
 @ IN SOA server1.centralsoft.org. root.localhost. (
2006012103; serial
28800; refresh, seconds
7200; retry, seconds
604800; expire, seconds
86400 ); minimum, seconds
;
NS server1.centralsoft.org.;
NS ns0.centralsoft.org. ;
42 PTR centralsoft.org.
45 PTR ns0.centralsoft.org.
Now we can test it by doing a lookup with the command line tool dig. First we
look up the IP address of centralsoft.org:
# dig centralsoft.org
; <<>> DiG 9.2.1 <<>> centralsoft.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48489
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;centralsoft.org. IN A
;; ANSWER SECTION:
centralsoft.org. 86400 IN A 70.253.158.42

;; Query time: 198 msec

;; SERVER: 81.169.163.104#53(81.169.163.104)
;; WHEN: Sat Mar 11 18:55:21 2006
;; MSG SIZE rcvd: 49
As you see, it returns the IP address 70.253.158.42.
Now we do a reverse lookup:
# dig -x 70.253.158.42
; <<>> DiG 9.2.1 <<>> -x 70.253.158.42
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;42.158.253.70.in-addr.arpa. IN PTR
;; ANSWER SECTION:
42.158.253.70.in-addr.arpa. 5304 IN PTR centralsoft.org.

;; Query time: 2 msec

;; SERVER: 81.169.163.104#53(81.169.163.104)
;; WHEN: Sat Mar 11 18:57:54 2006
;; MSG SIZE rcvd: 98
You see, the forward and the reverse lookup match each other!

Our Secondary Name Server

Next let's set up our secondary name server ns0.centralsoft.org. It will act as a
backup name server in case the primary (server1.centralsoft.org) fails so that
people can still look up ccentralsoft.org and its subdomains.
ns0.centralsoft.org's named.conf resembles that of the primary name server very
much, with a few differences:
 options {
pid-file "/var/run/bind/run/named.pid";
directory "/etc/bind";
// query-source address * port 53;
};
zone "." {
type hint;
file "db.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "db.local";
};
zone "centralsoft.org" {
type slave;
file "sec.centralsoft.org";
masters { 70.253.158.42; };
};
The most important part is this one:
zone "centralsoft.org" {
type slave;
file "sec.centralsoft.org";
masters { 70.253.158.42; };
};
By writing type slave, we define that this is a slave zone, and in the masters
line we specify the IP address of the primary name server. In the file line we
specify the file name where the slave zone should be stored.
That's all we have to do. Restart named, and soon afterwards you should find the
file /etc/bind/sec.centralsoft.org on your secondary name server. What has
happened? The secondary has contacted the primary name server, and the
primary name server has transferred the zone to the secondary.
Now whenever you update the zone on the primary name server, make sure you
increase the serial number, otherwise the updated zone will not be transferred to
the secondary!
Please make sure you have no firewall on the primary and the secondary name
server that blocks port 53 (TCP and UDP) because otherwise zone transfers will
fail!

A Word On Security
In our current configuration every name server is allowed to transfer our
centralsoft.org zone from our primary name server. Since we want only our
secondary name server (70.253.158.45) to be allowed to transfer the zone, we
add the following line to the centralsoft.org zone in named.conf on our primary
name server server1.centralsoft.org:
allow-transfer { 70.253.158.45; };
So the zone should look like this:
zone "centralsoft.org" {
type master;
file "pri.centralsoft.org";
allow-transfer { 70.253.158.45; };
};
Congratulations! You have just set up your first zone.