Never Ending Security

It starts all here

Complete Guide on, Linux Bind DNS


LINUX BIND DNS – INTRODUCTION TO THE DNS DATABASE (BIND)


BIND (Berkely Internet Name Domain) is a popular software for translating domain names into IP addresses and usually found on Linux servers. This article will explain the basic concepts of DNS BIND and analyse the associated files required to successfully setup your own DNS BIND server. After reading this article, you will be able to successfully install and setup a Linux BIND DNS server for your network.

ZONES AND DOMAINS

The programs that store information about the domain name space are called name servers, as you probably already know. Name Servers generally have complete information about some part of the domain name space (a zone), which they load from a file. The name server is then said to have authority for that zone.

The term zone is not one that you come across every day while you’re surfing on the Internet. We tend to think that the domain concept is all there is when it comes to DNS, which makes life easy for us, but when dealing with DNS servers that hold data for our domains (name servers), then we need to introduce the zone term since it is essential so we can understand the setup of a DNS server.

The difference between a zone and a domain is important, but subtle. The best way to understand the difference is by using a good example, which is coming up next.

The COM domain is divided into many zones, including the hp.com zone, sun.com, it.com. At the top of the domain, there is also a com zone.

The diagram below shows you how a zone fits within a domain:

 dns-bind-intro-1

The trick to understanding how it works is to remember that a zone exists “inside” a domain. Name servers load zone files, not domains.Zone files contain information about the portion of a domain for which they are responsible. This could be the whole domain (sun.com,it.com) or simply a portion of it (hp.com + pr.hp.com).

In our example, the hp.com domain has two subdomains, support.hp.com and pr.hp.com. The first one, support.hp.com is controlled by its own name servers as it has its own zone, called the support.hp.com zone. The second one though, pr.hp.com is controlled by the same name server that takes care of the hp.com zone.

The hp.com zone has very little information about the support.hp.com zone, it simply knows its right below. If anyone requires more information on support.hp.com, it will be requested to contact the authoritative name servsers for that subdomain, which are the name servers for that zone.

So you see that even though support.hp.com is a subdomain just like pr.hp.com, it is not setup and controlled the same way as pr.hp.com.

On the other hand, the Sun.com domain has one zone (sun.com zone) that contains and controlls the whole domain. This zone is loaded by the authoritative name servers.

BIND? NEVER HEARD OF IT !

As mentioned in the beginning of this article, BIND stands for Berkely Internet Name Domain. Keeping things simple, it’s a program you download (www.bind.org) and install on your Unix or Linux server to give it the ability to become a DNS server for your private (lan) or public (Internet) network.

The majority of DNS servers are based on BIND as it’s a proven and reliable DNS server. The download is approximately 4.8 MBytes. Untarring and compiling BIND is a pretty straight forward process and the steps required will depend on your Linux distribution and version. If you follow the instructions provided with the download, you shouldn’t have any problems.  For simplicity purposes, we assume you’ve compiled and installed the BIND program using the provided instructions.

SETTING UP YOUR ZONE DATA

No matter what Linux distribution you have, the file structure is pretty much the same. I have BIND installed on my Linux server, which runs Slackware v8 with kernel 2.4.19. By following the installation procedure found in the documentation provided with BIND, you will have the server installed within 15 min at most.

Once the installation of BIND is complete you need to start creating your zone data files. Remember, these are the files the DNS server will load in order to understand how your domain is setup and the various hosts within it.

A DNS server has multiple files that contain information about the domain setup. From these files, one will map all host names to IP Addresses and other files will map the IP Address back to hostnames. The name-to-IP Address lookup is sometimes called forward mapping and the IP Address-to-name lookup reverse mapping. Each network will have its own file for reverse-mapping.

As a convention in this section, a file that maps hostnames to IP Addresses will be called db.DOMAIN, where DOMAIN is the name of your domain e.g. db.firewall.cx, and db is short for DataBase.The files mapping IP Address to hostnames are called db.ADDR whereADDR is the network number without trailing zeros or the specification of a netmask, e.g db.192.168.0 for the 192.168.0.0 network.

The collection of our db.DOMAIN and db.ADDR files are our Zone Data files. There are a few other zone data files, some of which are created during the installation of BIND: named.ca, localhost.zone and named.local.

Named.ca contains information about the root servers on the Internet, should your DNS server require to contact one of them. Localhost.zone and Named.local are there to cover the loopback network. The loopback address is a special address hosts use to direct traffic to themselves. This is usually IP Address 127.0.0.1, which belongs to the 127.0.0.0/24 network.

These files must be present in each DNS server and are the same for every DNS server.

QUICK SUMMARY OF FILES SO FAR..

Let’s have a quick look at the files we have covered so far to make sure we don’t lose track:

1) Following files must be created by you and will contain the data for our zone:

  • db.DOMAIN e.g db.space.net – Host to IP Address mapping
  • db.ADDR e.g db.192.168.0 – IP Address to Host mapping

2) Following files are usually created by the BIND installation:

  • named.ca – Contains the ROOT DNS servers
  • named.local & localhost.zone – Special files so the server can direct traffic to itself.

You should also be aware that the file names can change, there is no standard for names, it’s just very convenient and tidy to keep some type of convention.

To tie all the zone data files together a name server needs a configuration file. BIND version 8 and above calls it named.conf and it can be found in your /etc dir once you install the BIND package. Named.conf simply tells the name server where your zone files are located and we will be analysing this file later on.

Most entries in the zone data files are called DNS resource records. Since DNS lookups are case insensitive, you can enter names in your zone data files in uppercase, lowercase or mixed case. I tend to use lowercase.

Resource records must start in the first column of a line. The DNS RFCs have samples that present the order in which one should enter the resource records. Some people choose to follow this order, while others don’t. You are not required to follow this order, but I do :)

Here is the order of resource records in the zone data file:

SOA record – Indicates authority for this zone.

NS record – Lists a name server for this zone

MX record – Indicates the mail exchange server for the domain

A record – Name to IP Address mapping (gives the IP Address for a host)

CNAME record – Canonical name (used for aliases)

PTR record – Address to name mapping (used in db.ADDR)

The next article deals with the construction of our first zone data file, db.firewall.cx of our example firewall.cx domain.


LINUX BIND DNS – CONFIGURING DB.DOMAIN ZONE DATA FILE


It’s time to start creating our zone files. We’ll follow the standard format, which is given in the DNS RFCs, in order to keep everything neat and less confusing.

First step is to decide on the domain we’re using and we’ve decided on the popular firewall.cx. This means that the first zone file will bedb.firewall.cx. Note that this file is to be placed on the Master DNS server for our domain.

We will progressively build our database by populating it step by step and explaining each step we take. At the end of the step-by-step example, we’ll grab each step’s data and put it all together so we can see how the final version of our file will look. We strongly beleive, this is the best method of explaining how to create a zone file without confusing the hell out of everyone!

CONSTRUCTING DB.FIREWALL.CX – DB.DOMAIN

It is important at this point to make it clear that we are setting up a primary DNS server. For a simple DNS caching or secondary name server, the setup is a lot simpler and covered on the articles to come.

The first entry for our file is the Default TTL – Time To Live. This is defined using the $TTL control statement. $TTL specifies the time to live for all records in the file that follow the statement and don’t have an explicit TTL. We are going to set ours to 24 hours – 86400 seconds.

The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are “per record” and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide.   Dynamic DNS (DDNS) usually have the TTL value set to 5 minutes, or 300 seconds.

Next up is the SOA Record. The SOA (Start Of Authority) resource record indicates that this name server is the best source of information for the data within this zone (this record is required in each db.DOMAIN and db.ADDR file), which is the same as saying this name server is Authoritative for this zone. There can be only one SOA record in every data zone file (db.DOMAIN).

$TTL 86400

firewall.cx. IN SOA voyager.firewall.cx. admin.voyager.firewall.cx. (

                            1 ; Serial Number

3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 hour

Let’s explain the above code:

firewall.cx. is the domain name and must always be stated in the first column of our line, be sure you include the trailing dot “.” after the domain name, we’ll explain later on why this is needed.

The IN stands for Internet. This is one class of data and while other classes exist, you won’t see them at all because they are not used :)

The SOA is an important resource record. What follows is the actual primary name server for firewall.cx. In our example, this is the server named “voyager” and its Fully Qualified Domain Name (FQDN) is voyager.firewall.cx. Notice the trailing “.” is present here as well.

Next up is the entry admin.voyager.firewall.cx. which is the email address of the person responsible for this domain. Take the dot “.” after the admin entry and replace it with a “@” and you have a valid email address: admin@voyager.firewall.cx. Most times you will see root, postmaster or hostmaster instead of “admin”.

The “(” parentheses allow the SOA record to span more than one line, while in most cases the fields that follow are used by the secondary name servers and any other name server requesting information about the domain.

The serial number “1 ; Serial Number” entry is used by the secondary name server to keep track of changes that might have occured in the master’s zone file. When the secondary name server contacts the primary name server, it will check to see if this value is the same. If the secondary’s name server is lower than the primary’s, then its data is out of date and, when equal, it means the data is up to date. This means when you make any modifications to the primary’s zone file, you must increment the serial number at least by one.

Note that anything after the semicolon (;) is considered a remark and not taken into consideration by the DNS BIND Service. This allows us to create easy-to-understand comments for future reference.

The refresh “3h ; Refresh after 3 hours” tells the secondary name server how often to check the primary’s server’s data, to ensure its copy for this zone is up to date.

If the secondary name server tries to contact the primary and fails, the retry “1 h ; Retry after 1 hour” is used to tell the secondary name server how long to wait until it tries to contact the primary again.

If the secondary name server fails to contact the primary for longer than the time specified in the fourth entry “1 w ; Expire after 1 week“, then the zone data on the secondary name server is considered too old and will expire.

The last line “1 h ) ; Negative caching TTL of 1 day” is how long a name server will send negative responses about the zone. These negative responses say that a particular domain or type of data sought for a particular domain name doesn’t exist. Notice the SOA section finishes with the “)” parentheses.

Next up in the file are the name server (NS) records:

; Name Servers defined here

firewall.cx. IN NS voyager.firewall.cx.

firewall.cx. IN NS gateway.firewall.cx.

These entries define the two name servers (voyager and gateway) for our domain firewall.cx. These entries will be also in the db.ADDR file for this domain as we will see later on.

It’s time to enter our MX records. These records define the mail exchange servers for our domain, and this is how any client, host or email server is able to find a domain’s email server:

; Mail Exchange servers defined here

firewall.cx. IN MX 10 voyager.firewall.cx.

firewall.cx. IN MX 20 gateway.firewall.cx.

Let’s explain what exactly these entries mean. The first line specifies that voyager.firewall.cx is a mail exchanger for firewall.cx, just as the second line (…IN MX 20 gateway…) specifies that gateway.firewall.cx is also a mail exchanger for the domain. The MX record indicates that the following hosts are mail exchanger servers for the domain and the numbers 10 and 20 indicate the priority level. The smaller the number, the higher the priority.

This means that voyager.firewall.cx is a higher priority mail server than gateway.firewall.cx.  If another server trying to send email to firewall.cx fails to contact the highest priority mail server (voyager.firewall.cx), it will then fall back to the secondary, in which our case is gateway.firewall.cx.

These entries were introduced to prevent mail loops. When another email server (unlikely for a private domain like mine, but the same rule applies for the Internet) wants to send mail to firewall.cx, it will try to contact first the mail exchanger with the smallest number, which in our case is voyager.firewall.cx. The smaller the number, the higher the priority if there are more than one mail servers.

In our example, if we replaced:

firewall.cx. IN MX 10 voyager.firewall.cx.

firewall.cx. IN MX 20 gateway.firewall.cx.

with

firewall.cx. IN MX 50 voyager.firewall.cx.

firewall.cx. IN MX 100 gateway.firewall.cx.

the result in matter of server priority, would be the same.

Let’s now have a look our next part of our zone file: Host IP Addresses and Alias records:

; Host addresses defined here

localhost.firewall.cx. IN A 127.0.0.1

voyager.firewall.cx. IN A 192.168.0.15

enterprise.firewall.cx. IN A 192.168.0.5

gateway.firewall.cx. IN A 192.168.0.10

admin.firewall.cx. IN A 192.168.0.1

; Aliases

http://www.firewall.cx. IN CNAME voyager.firewall.cx.

Most fields in this section are easy to understand. We start by defining our localhost (local loopback) “localhost.firewall.cx. IN A 127.0.0.1” and continue with the servers on our private network, these include voyager, enterprise, gateway and admin. The “A” record stands for IP Address. So “voyager.firewall.cx. IN A 192.168.0.15” translates to a host called voyager located in the firewall.cx domain with an INternet ip Address of 192.168.0.15. See the pattern? :)

The second block has the aliases table, where we created a Canonical Name (CNAME) record. A CNAME record simply maps an alias to its canonical name; in our example, www is the alias and voyager.firewall.cx is the canonical name.

When a name server looks up a name and finds CNAME records, it replaces the name (alias – www) with its canonical name (voyager.firewall.cx) and looks up the canonical name (voyager.firewall.cx).

For example, when a name server looks up http://www.firewall.cx, it will replace the ‘www‘ with ‘voyager‘ and lookup the IP Address forvoyager.firewall.cx.

This also explains the existance of “www” in all URLs – it’s nothing more than an alias which, ultimately, is replaced with the CNAMErecord defined.

THE COMPLETE DB.DOMAIN CONFIGURATION FILE

That completes a simple domain setup! We have now created a working zone file that looks like this:

$TTL 86400

firewall.cx. IN SOA voyager.firewall.cx. admin.voyager.firewall.cx. (

                            1 ; Serial Number

3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 hour

; Name Servers defined here

firewall.cx. IN NS voyager.firewall.cx.

firewall.cx. IN NS gateway.firewall.cx.

; Mail Exchange servers defined here

firewall.cx. IN MX 10 voyager.firewall.cx.

firewall.cx. IN MX 20 gateway.firewall.cx.

; Host Addresses Defined Here

localhost.firewall.cx. IN A 127.0.0.1

voyager.firewall.cx. IN A 192.168.0.15

enterprise.firewall.cx. IN A 192.168.0.5

gateway.firewall.cx. IN A 192.168.0.10

admin.firewall.cx. IN A 192.168.0.1

; Aliases

http://www.firewall.cx. IN CNAME voyager.firewall.cx.

 

A quick glance at this file tells you a lot about our lab domain firewall.cx, and this is probably the best time to explain why we should not omit the trailing dot at the end of the domain name:

If we took gateway.firewall.cx as an example and omitted the dot “.” at the end of our entries, the system would translate it like this:gateway.firewall.cx.firewall.cx – definately not  what we want!

As you see, the ‘firewall.cx‘ is appended to the end of our Fully Qualified Domain Name for the particular resource record (gateway). This is why it’s so important to never forget that extra dot “.” at the end!

Our next article will cover the db.ADDR file, which will take the name db.192.168.0. for our example.


LINUX BIND DNS – CONFIGURING THE DB.192.168.0 ZONE DATA FILE


The db.192.168.0 zone data file is the second file we are creating for our DNS server. As outlined in the DNS-BIND Introduction, this file’s purpose is to provide the IP Address -to- name mappings. Note that this file is to be placed on the Master DNS server for our domain.

CONSTRUCTING DB.192.168.0

While we start to construct the file, you will notice many similarities with our previous file. Most resource records have already been covered and explained in our previous articles and therefore we will not repeat on this page.

The first line is our $TTL control statement, followed by the Start Of Authority (SOA) resource record:

$TTL 86400

0.168.192.in-addr.arpa. IN SOA voyager.firewall.cx. admin.firewall.cx. (

1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after one week
1h ) ; Negative Caching TTL of 1 hourAs you can see, everything above, except the first column of the first line, is identical to the db.firewall.cx file. The “0.168.192.in-addr.arpa” entry is our IP network in reverse order. The trick to figure out your own in-addr.arpa entry is to simply take your network address, reverse it, and add an “.in-addr.arpa.” at the end

Name server resource records are next, follwed by the PTR resource record that creates our IP Address-to-name mappings. The syntax is nearly the same as the db.domain file, but keep in mind that we don’t enter the full reversed IP Address for the name servers but only the first 3 octecs which represent the network they belong to:

; Name Servers defined here
0.168.192.in-addr.arpa. IN NS voyager.firewall.cx.

0.168.192.in-addr.arpa. IN NS gateway.firewall.cx.

; IP Address to Name mappings
1.0.168.192.in-addr.arpa. IN PTR admin.firewall.cx.
5.0.168.192.in-addr.arpa. IN PTR enterprise.firewall.cx.
10.0.168.192.in-addr.arpa. IN PTR gateway.firewall.cx.
15.0.168.192.in-addr.arpa. IN PTR voyager.firewall.cx.

Time to look at the configuration file with all its entries:

$TTL 86400

0.168.192.in-addr.arpa. IN SOA voyager.firewall.cx. admin.firewall.cx. (

1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after one week
1h ) ; Negative Caching TTL of 1 hour

; Name Servers defined here
0.168.192.in-addr.arpa. IN NS voyager.firewall.cx.
0.168.192.in-addr.arpa. IN NS gateway.firewall.cx.

; IP Address to Name mappings
1.0.168.192.in-addr.arpa. IN PTR admin.firewall.cx.
5.0.168.192.in-addr.arpa. IN PTR enterprise.firewall.cx.
10.0.168.192.in-addr.arpa. IN PTR gateway.firewall.cx.
15.0.168.192.in-addr.arpa. IN PTR voyager.firewall.cx.

This completes the db.192.168.0 Zone data file.

Remember the whole purpose of this file is to provide an IP Address-to-name mapping, which is why we do not use the domain name in front of each line, but the reversed IP Address followed by the in-addr.arpa. entry.


LINUX BIND DNS – COMMON BIND FILES – NAMED.LOCAL, NAMED.CONF, DB.127.0.0 ETC


So far we have covered in great detail the main files required for the firewall.cx domain. These files, which we named db.firewall.cx and db.192.168.0, define all the resouce records and hosts available in the firewall.cx domain.

We will be analysing these files in this article, to help you understand why they exist and how they fit into the big picture :)

OUR COMMON FILES

There are 3 common files that we’re going to look at, of which the first two files contents change slightly depending on the domain. This happens because they must be aware of the various hosts and the domain name for which they are created. The third file in the list below, is always the same amongst all DNS servers and we will explain more about it later on.

So here are our files:

  • named.local or db.127.0.0
  • named.conf
  • named.ca or db.cache

THE NAMED.LOCAL FILE

The named.local file, or db.127.0.0 as some might call it, is used to cover the loopback network. Since no one was given the responsibility for the 127.0.0.0 network, we need this file to make sure there are no errors when the DNS server needs to direct traffic to itself (127.0.0.1 IP Address – Loopback).

When installing BIND, you will find this file in your caching example directory: /var/named/caching-example, so you can either create a new one or modify the existing one to meet your requirements.

The file is no different than our example db.addr file we saw previously:

$TTL 864000.0.127.in-addr.arpa. IN SOA voyager.firewall.cx. admin.firewall.cx. (

1 ; Serial
3h ; Refresh after 3 hours
1h ; Retry after 1 hour
1w ; Expire after 1 week
1h ) ; Negative caching TTL of 1 hour

0.0.127.in-addr.arpa. IN NS voyager.firewall.cx.
0.0.127.in-addr.arpa. IN NS gateway.firewall.cx.
1.0.0.127.in-addr.arpa. IN PTR localhost.

That’s all there is for named.local file !

THE NAMED.CA FILE

The named.ca file (also known as the “root hints file”) is created when you install BIND and dosen’t need to be modified unless you have an old version of BIND or it’s been a while since you installed BIND.

The purpose of this file is to let your DNS server know about the Internet ROOT Servers. There is no point displaying all of the file’s content because it’s quite big, so we will show an entry of a ROOT server to get the idea what it looks like:

; last update: Aug 22, 2011
; related version of root zone: 1997082200
; formerly NS.INTERNIC.NET

. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

The domain name “.” refers to the root zone and the “3600000” is an explicit time to live for the records in the file, but it is generally ignored :)

The rest are self explanatory. If you want to grab a new copy of the root hint file you can ftp to ftp.rs.internic.net (198.41.0.6) and log on anonymously, there you will find the latest up to date version.

 

THE NAMED.CONF FILE

The named.conf file is usually located in the /etc directory and is the key file that ties all the zone data files together and lets the DNS server know where they are located in the system. This file is automatically created during the installation but you must edit it in order to add new entries that will point to any new zone files you have created.

Let’s have a close look at the named.conf file and explain:

options {
directory “/var/named”;

};

// Root Servers
zone “.” IN {
type hint;
file “named.ca”;
};

// Entry for Firewall.cx – name to ip mapping
zone “firewall.cx” IN {
type master;
file “db.firewall.cx”;
};

// Entry for Firewall.cx – ip to name mapping
zone “0.168.192.in-addr.arpa” IN {
type master;
file “db.192.168.0”;
};

// Entry for Local Loopback
zone “0.0.127.in-addr.arpa” IN {
type master;
file “named.local”;
};

At first glance it might seem a maze, but it’s a lot simpler than you think. Break down each paragraph and you can see clearly the pattern that follows.

Starting from the top, the options section simply defines the directory where all the files to follow are located, the rest are simply comments.

The root servers section tells the DNS server where to find the root hints file, which contains all the root servers.

Next up is the entry for our domain firewall.cx, we let the DNS server know which file contains all the zone entries for this domain and let it know that it will act as a master DNS server for the domain. The same applies for the entry to follow, which contains the IP to Name mappings, this is the 0.168.192.in-addr.arpa zone.

The last entry is required for the local loopback. We tell the DNS server which file contains the local loopback entries.

Notice the “IN” class that is present in each section? If we accidentally forget to include it in our zone files, it wouldn’t matter because the DNS server will automatically figure out the class from our named.conf file. It’s imperative not to forget the “IN” (Internet) class in thenamed.conf, whereas it really doesnt matter if you don’t put it in the zone files. It’s good practice still to enter it in the zone files as we did, just to make sure you don’t have any problems later on.

And that ends our discussion for the common DNS (BIND) files.  Next up is the configuration of our Linux BIND Slave/Secondary DNS server.


THE LINUX BIND SETUP & CONFIGURE SECONDARY (SLAVE) DNS SERVER


Setting up a Secondary (or Slave) DNS sever is much easier than you might think. All the hard work is done when you setup the Master DNS server by creating your database zone files and configuring named.conf.

If you are wondering how is it that the Slave DNS server is easy to setup, well you need to remember that all the Slave DNS server does is update its database from the Master DNS server (zone transfer) so almost all the files we configure on the Master DNS server are copied to the Slave DNS server, which acts as a backup in case the Master DNS server fails.

SETTING UP THE SLAVE DNS SERVER

Let’s have a closer look at the requirements for getting our Slave DNS server up and running.

Keeping in mind that the Slave DNS server is on another machine, we are assuming that you have downloaded and successfully installed the same BIND version on it. We need to copy 3 files from the Master DNS server, make some minor modifications to one file and launch our Slave DNS server…. the rest will happen automatically :)

SO WHICH FILES DO WE COPY?

The files required are the following:

  • named.conf (our configuration file)
  • named.ca or db.cache (the root hints file, contains all root servers)
  • named.local (local loopback for the specific DNS server so it can direct traffic to itself)

The rest of the files, which are our db.DOMAIN (db.firewall.cx for our example) and db.in-addr.arpa (db.192.168.0 for our example), will be transferred automatically (zone transfer) as soon as the newly brought up Slave DNS server contacts the Master DNS server to check for any zone files.

HOW DO I COPY THE FILES?

There are plenty of ways to copy the files between servers. The method you will use depends on where the servers are located. If, for example, they are right next to you, you can simply use a floppy disk to copy them or use ftp to transfer them.

If you’re going to try to transfer them over a network, and especially over the Internet, then you might consider something more secure than ftp. We would recommend you use SCP, which stands for Secure Copy and uses SSH (Secure SHell).

SCP can be used independently of SSH as long as there is an SSH server on the other side. SCP will allow you to transfer files over an encrypted connection and therefore is preferred for sensitive files, plus you get to learn a new command :)

The command used is as follows: scp localfile-to-copy username@remotehost:desitnation-folder. Here is the command line we used from our Gateway server (Master DNS): scp /etc/named.conf root@voyager:/etc/

Keep in mind that the files we copy are placed in the same directory as on the Master DNS server. Once we have copied all three files we need to modify the named.conf file. To make things simple, we are going to show you the original file copied from the Master DNS and the modified version which now sits on the Slave DNS server.

The Master named.conf file is a clear cut/paste from the “Common BIND Files” page, whereas the Slave named.conf has been modifed to suit our Slave DNS server. To help you identify the changes, we have marked them in red:

Master named.conf file

options {
directory “/var/named”;

};

// Root Servers
zone “.” IN {
type hint;
file “named.ca”;
};

// Entry for Firewall.cx – name to ip mapping
zone “firewall.cx” IN {
type master;
file “db.firewall.cx”;
};
// Entry for firewall.cx – ip to name mapping
zone “0.168.192.in-addr.arpa” IN {
type master;
file “db.192.168.0”;
};

// Entry for Local Loopback
zone “0.0.127.in-addr.arpa” IN {
type master;
file “named.local”;
};

Slave named.conf file

options {
directory “/var/named”;

};

// Root Servers
zone “.” IN {
type hint;
file “named.ca”;
};

// Entry for Firewall.cx – name to ip mapping
zone “firewall.cx” IN {
type slave;
file “bak.firewall.cx”;
masters { 192.168.0.10 ; } ;
};

// Entry for firewall.cx – ip to name mapping
zone “0.168.192.in-addr.arpa” IN {
type salve;
file “bak.192.168.0”;
masters { 192.168.0.10 ; } ;
};

// Entry for Local Loopback
zone “0.0.127.in-addr.arpa” IN {
type master;
file “named.local”;
};

As you can see, most of the slave’s named.conf file is similair to the master’s, except for a few fields and values, which we are going to explain right now.

The type value is now slave, and that’s pretty logical since it tells the dns server if it’s a master or slave.

The file “bak.firewall.cx“; entry basically tells the server what name to give the zone files once they are transfered from the master dns server. We tend to follow the bak.domain format because that’s the way we see the slave server, a backup dns server. It is not imperative to use this name scheme, you can change it to whatever you wish. Once the server is up and running, you will see these files soon appear in the /var/named directory.

Lastly, the masters {192.168.0.10}; entry informs our slave server that this is the IP Address of the master DNS which it needs to contact and retrieve the zone files.

That’s all there is to setup the slave DNS server ! As we mentioned, once the master is setup, the slave is a peice of cake cause it involves very few changes.

Our Final article covers the setup of  Linux BIND DNS Caching


LINUX BIND – DNS CACHING


In the previous articles, we spoke about the Internet Domain Hierarchy and explained how the ROOT servers are the DNS servers, which contain all the information about authoritative DNS servers the domains immediately below e.g firewall.cx, microsoft.com. In fact, when a request is passed to any of the ROOT DNS servers, they will redirect the client to the appropriate authoritative DNS server, that is, the DNS server in charge of the domain.

For example, if you’re trying to resolve firewall.cx and your machine contacts a ROOT DNS server, the server will point your computer to the DNS server in charge of the .CX domain, which in turn will point your computer to the DNS server in charge of firewall.cx, currently server with IP 74.200.90.5.

THE BIG PICTURE

As you can see, a simple DNS request can become quite a task in order to successfully resolve the domain. This also means that there’s a fair bit of traffic generated in order to complete the procedure. Whether you’re paying a flat rate to your ISP or your company has a permanent connection to the Internet, the truth is that someone ends up paying for all these DNS requests ! The above example was only for one computer trying to resolve one domain. Try to imagine a company that has 500 computers connected to the Internet or an ISP with 150,000 subscribers – Now you’re starting to get the big picture!

All that traffic is going to end up on the Internet if something isn’t done about it, not to mention who will be paying for it !

This is where DNS Caching comes in. If we’re able to cache all these requests, then we don’t need to ask the ROOT DNS or any other external DNS server as long as we are trying to resolve previously visited sites or domains, because our caching system would “remember” all the previous domains we visited (and therefore resolved) and would be able to give us the IP Address we’re looking for !

Note: You should keep in mind that when you install BIND, by default it’s setup to be a DNS Caching server, so all you need to do it startup the service, which is called ‘named’.

Almost all Internet name servers use name caching to optimise search costs. Each of these servers maintains a cache which contains all recently used names as well as a record of where the mapping information for that name was obtained. When a client (e.g your computer) asks the server to resolve a domain, the server will first check to see whether it has authority (meaning if it is in charge) for that domain. If not, the server checks its cache to see if the domain is in there and it will find it if it’s been recently resolved.

Assuming that the server does find it in the cache, it will take the information and pass it on to the client but also mark the information as a nonauthoritative binding, which means the server tells the client “Here is the information you required, but keep in mind, I am not in charge of this domain”.

The information can be out of date and, if it is critical for the client that it does not receive such information, it will then try to contact the authoritative DNS server for the domain and obtain the up to date information it requires.

DNS CACHING DOES COME WITH ITS PROBLEMS!

As you can clearly see, DNS caching can save you a lot of money, but it comes with its problems !

Caching does work well in the domain name system because name to address binding changes infrequently. However, it does change. If the servers cached the information the first time it was requested and never change that information, the entries in the cache could become incorrect.

 

THE SOLUTION

Fortunately there is a solution that will prevent DNS servers from giving out incorrect information. To ensure that the information in the cache is correct, every DNS server will time each entry and dispose of the ones that have exceeded a reasonable time. When a DNS server is asked for the information after it has removed the entry from its cache, it must go back to the authoritative source and obtain it again.

Whenever an authoritative DNS server responds to a request, it includes a Time To Live (TTL) value in the response. This TTL value is set in the zone files as you’ve probably already seen in the previous pages.

If you manage DNS server an are planning to introduce changes like redelegate (move) your domain to some other hosting company or if the IP Address your website currently has or changing mail servers, in the next couple weeks, then it’s a good idea to get your TTL changes to a very small value well before the scheduled changes. Reason for this is because any dns server that will query your domain, website or any resource record that belongs to your domain, will cache the data for the amount of time the TTL is set.

By decreasing the $TTL value to e.g 1 hour, this will ensure that all dns data from your domain will expire in the requesters cache 1 hour after it was received. If you didn’t do this, then the servers and clients (simple home users) who access your site or domain, will cache the dns data for the currently set time, which is normaly around 3 days. Not a good thing when you make a big change :)

So keep in mind all the above when your about the perform a change in the DNS server zone files. a couple of days before making the change, decrease the $TTL value to a reasonable value, not more than a few hours, and then once you complete the change, be sure you set it back to what it was.

We hope this has given you an insight on how you can save yourself, or company money and problems which occur when changing field and values in the DNS zone files!

One response to “Complete Guide on, Linux Bind DNS

  1. ihialzrgb@gmail.com 18 May 2015 at 21:25

    Hello Web Admin, I noticed that your On-Page SEO is is missing a few factors, for one you do not use all three H tags in your post, also I notice that you are not using bold or italics properly in your SEO optimization. On-Page SEO means more now than ever since the new Google update: Panda. No longer are backlinks and simply pinging or sending out a RSS feed the key to getting Google PageRank or Alexa Rankings, You now NEED On-Page SEO. So what is good On-Page SEO?First your keyword must appear in the title.Then it must appear in the URL.You have to optimize your keyword and make sure that it has a nice keyword density of 3-5% in your article with relevant LSI (Latent Semantic Indexing). Then you should spread all H1,H2,H3 tags in your article.Your Keyword should appear in your first paragraph and in the last sentence of the page. You should have relevant usage of Bold and italics of your keyword.There should be one internal link to a page on your blog and you should have one image with an alt tag that has your keyword….wait there’s even more Now what if i told you there was a simple WordPress plugin that does all the On-Page SEO, and automatically for you? That’s right AUTOMATICALLY, just watch this 4minute video for more information at. Seo Plugin

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s