Traditional DNS Howto (BIND)

Source: http://www.howtoforge.com/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 of64.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 zonefiles. 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
  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

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 fileline 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 ourprimary 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!