Skip to main content

Linux BIND DNS - Part 1: 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 where ADDR 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 Our Files

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 (Part 2) deals with the construction of our first zone data file, db.firewall.cx of our example firewall.cx domain.

 

 

Your IP address:

18.97.9.174

All-in-one protection for Microsoft 365

All-in-one protection for Microsoft 365

FREE Hyper-V & VMware Backup

FREE Hyper-V & VMware Backup

Wi-Fi Key Generator

Generate/Crack any
WEP, WPA, WPA2 Key!

Network and Server Monitoring

Network and Server Monitoring

Follow Firewall.cx

Cisco Password Crack

Decrypt Cisco Type-7 Passwords on the fly!

Decrypt Now!

Bandwidth Monitor

Zoho Netflow Analyzer Free Download

Free PatchManager

Free PatchManager

EventLog Analyzer

ManageEngine Eventlog Analyzer

Security Podcast

Hornet-Security-The-Swarm-Podcast

Firewall Analyzer

zoho firewall analyzer