http://www.howtoforge.com/traditional_dns_howto
Traditional DNS Howto
Version 1.0
Authors: Tom Adelstein
Falko Timme
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> 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!