Introduction

DNS is important. The Domain Name Service is perhaps the most overlooked component of routine Internet services. When it becomes compromised or fails, the consequences can be far reaching and even catastrophic. To control DNS is to potentially control everything since modifying DNS services can redirect any user anywhere. It doesnt take a rocket scientist to understand the dramatic consequences of redirecting paypal.com to hackedpaypal.com and have all users innocently punching in their login details for collection in a nasty database somewhere.

DNS is also convenient. Setting your browser to use the bbc.co.uk website wouldnt be quite so easy if you had to refer to it as 212.58.246.104. Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases the configuration of services and applications, and increases the maintainability of configuration files.

As I am currently setting up some of my own internal nameservers, I decide to create a guide for my blog. In this post, I will go over how to set up an internal DNS server, using the BIND name server software (BIND9), that can be used by your own private network in the home or business to resolve host names and IP addresses. This provides a central way to manage your own hostnames and IP addresses, which is indispensable when your environment expands to more than a few hosts.

DNS Hosts

We will be setting up the new DNS servers in our office in London serving the technofatty domain. With this assumption, we decide that it makes sense to use a naming scheme that uses "ldn1.technofatty.com" to refer to our private subnet or zone. Therefore, host1's private Fully-Qualified Domain Name (FQDN) will be "pc1.ldn1.technofatty.com". Refer to the following table the relevant details:

Host

Role

Private FQDN

Private IP Address

host1

User PC 1

pc1.ldn1.technofatty.com

192.168.1.101

host2

DVR 1

dvr1.ldn1.technofatty.com

192.168.1.102

Note: Your own setup will be different, but the example names and IP addresses given will be used to demonstrate how to configure a DNS server to provide a functioning internal DNS. You should be able to adapt this setup to your own environment fairly simply by replacing the host names and private IP addresses with your own. It is not necessary to use the region name of the site in your naming scheme, but we use it here to denote that these hosts belong to a particular sites private network. If you have multiple sites, you can set up an internal DNS within each respective site.

Our Goal

By the end of this tutorial, we will have a primary DNS server, ns1, as well as a secondary DNS server,ns2, which will operate as a backup.

Here is a table with example names and IP addresses:

Host

Role

Private FQDN

Private IP Address

ns1

Pri DNS Server

ns1.ldn1.technofatty.com

192.168.1.1

ns2

Sec DNS Server

ns2.ldn1.technofatty.com

192.168.1.2

Let's get started by installing our Primary DNS server, ns1.

Install BIND on Primary Server

On both DNS servers, ns1 and ns2, carry out apt-get update

sudo apt-get update

Next install BIND:

sudo apt-get install bind9 bind9utils bind9-doc

IPv4 Mode

Next we need to set BIND to IPv4 mode. On both servers, edit the bind9 startup options file:

sudo nano /etc/default/bind9

Add "-4" to the OPTIONS variable. It should look like the following:

OPTIONS="-4 -u bind"

Save and exit.

OK onwards to configure the primary DNS server.

Configure Primary DNS Server

BIND's configuration consists of multiple files, which are included from the main configuration file, named.conf. These filenames begin with "named" because that is the name of the process that BIND runs. We will start with configuring the options file. The default contents of this file are shown below:

// This is the primary configuration file for the BIND DNS server named.//// Please read /usr/share/doc/bind9/README.Debian.gz for information on the// structure of BIND configuration files in Debian, *BEFORE* you customize// this configuration file.//// If you are just adding zones, please do that in /etc/bind/named.conf.local

Configure Options File

As you can see from the above, the first file that is included is named.conf.options. On ns1, open the named.conf.options file for editing:

sudo nano /etc/bind/named.conf.options

Above the existing options block, create a new ACL block called "trusted". This is where we will define list of clients that we will allow recursive DNS queries from (i.e. your servers that are in the same datacenter as ns1). Using our example private IP addresses, we will add ns1, ns2, host1, and host2 to our list of trusted clients:

If your servers span more than one subnet but are on the same site, dont forget to specify an additional zone and zone file for each seperate subnet.

Once finished adding all of your required zones, save and exit the named.conf.local file.

Now that our zones are specified in BIND, we need to create the corresponding forward and reverse zone files.

Create Forward Zone File

The forward zone file is where we define DNS records for forward DNS lookups. That is, when the DNS receives a name query, "host1.nyc2.example.com" for example, it will look in the forward zone file to resolve host1's corresponding private IP address.

Let's create the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/bind/zones:

sudo mkdir /etc/bind/zones

It is simplest to base our forward zone file on the sample db.local zone file which is installed by default. Copy it to the proper location with the following commands:

First, you will want to edit the SOA record. Replace the first "localhost" with ns1's FQDN, then replace "root.localhost" with "admin.ldn1.technofatty.com". Also, every time you edit a zone file, you should increment the serial value before you restart the named process--we will increment it to "3". It should look something like this:

Then add the A records for your hosts that belong in this zone. This includes any server whose name we want to end with ".ldn1.technofatty.com" (substitute the names and private IP addresses). Using our example names and private IP addresses, we will add A records for ns1, ns2, pc1, and dvr1 like so:

; name servers - A records
ns1.ldn1.technofatty.com. IN A 192.168.1.1
ns2.ldn1.technofatty.com. IN A 192.168.1.2

; 192.168.1.0/24 - A recordspc1.ldn1.technofatty.com. IN A 192.168.1.101dvr1.ldn1.technofatty.com. IN A 192.168.1.102

; name servers - A records
ns1.ldn1.technofatty.com. IN A 192.168.1.1
ns2.ldn1.technofatty.com. IN A 192.168.1.2

; 192.168.1.0/24 - A recordspc1.ldn1.technofatty.com. IN A 192.168.1.101dvr1.ldn1.technofatty.com. IN A 192.168.1.102

Next we move on to the reverse zone file(s).

Create Reverse Zone File(s)

Reverse zone file are where we define DNS PTR (pointer) records for reverse DNS lookups. That is, when the DNS receives a query by IP address, "192.168.1.101" for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, "pc1.ldn1.technofatty.com" in this case.

On ns1, for each reverse zone specified in the named.conf.local file, create a reverse zone file. We will base our reverse zone file(s) on the sample db.127 zone file. Copy it to the proper location with the following commands (substituting the destination filename so it matches your reverse zone definition):

cd /etc/bind/zones
sudo cp ../db.127 ./db.168.192

Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:

Then add PTR records for all of your servers whose IP addresses are on the subnet of the zone file that you are editing. In our example, this includes all of our hosts because they are all on the 10.128.0.0/16 subnet. Note that the first column consists of the last two octets of your servers' private IP addresses in reversed order. Be sure to substitute names and private IP addresses to match your servers:

Check BIND Configuration Syntax

Run the following command to check the syntax of the named.conf* files:

sudo named-checkconf

If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. If there are problems with your configuration files, review the error messages then re-try named-checkconf .

The named-checkzone command can be used to check the correctness of your zone files. Its first argument specifies a zone name, and the second argument specifies the corresponding zone file, which are both defined in named.conf.local.

For example, to check the "ldn1.technofatty.com" forward zone configuration, run the following command (change the names to match your forward zone and file):

sudo named-checkzone ldn1.technofatty.com db.ldn1.technofatty.com

And to check the "168.192.in-addr.arpa" reverse zone configuration, run the following command (change the numbers to match your reverse zone and file):

sudo named-checkzone 168.192.in-addr.arpa /etc/bind/zones/db.168.192

When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service.

Restart BIND

Restart BIND:

sudo service bind9 restart

Your primary DNS server is now setup and ready to respond to DNS queries. Let's move on to creating the secondary DNS server.

Configure Secondary DNS Server

In most environments, it is a good idea to set up a secondary DNS server that will respond to requests if the primary becomes unavailable. Luckily, the secondary DNS server is much easier to configure.

On ns2, edit the named.conf.options file:

sudo nano /etc/bind/named.conf.options

At the top of the file, add the ACL with the private IP addresses of all of your trusted servers:

Save and exit named.conf.options. This file should look exactly like ns1's named.conf.options file except it should be configured to listen on ns2's private IP address.

Now edit the named.conf.local file:

sudo nano /etc/bind/named.conf.local

Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is "slave", the file does not contain a path, and there is a masters directive which should be set to the primary DNS server's private IP. If you defined multiple reverse zones in the primary DNS server, make sure to add them all here:

Run the following command to check the validity of your configuration files:

sudo named-checkconf

Once that checks out, restart bind

sudo service bind9 restart

Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers.

Configure DNS Clients

Before all of your servers in the "trusted" ACL can query your DNS servers, you must configure each of them to use ns1 and ns2 as nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file.

Ubuntu Clients

On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:

sudo nano /etc/resolvconf/resolv.conf.d/head

Add the following lines to the file (substitute your private domain, and ns1 and ns2 private IP addresses):

Now save and exit. Your client is now configured to use your DNS servers.

Test Clients

Use nslookup to test if your clients can query your name servers. You should be able to do this on all of the clients that you have configured and are in the "trusted" ACL.

Forward Lookup

For example, we can perform a forward lookup to retrieve the IP address of pc1.ldn1.technofatty.com by running the following command:

nslookup pc1

Querying "pc1" expands to "pc1.ldn1.technofatty.com because the search option is set to your private subdomain, and DNS queries will attempt to look on that subdomain before looking for the host elsewhere. The output of the command above would look like the following:

If all of the names and IP addresses resolve to the correct values, that means that your zone files are configured properly. If you receive unexpected values, be sure to review the zone files on your primary DNS server (e.g. db.ldn1.technofatty.com and db.168.192).

Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records.

Maintaining DNS Records

Now that you have a working internal DNS, you need to maintain your DNS records so they accurately reflect your server environment.

Adding Host to DNS

Whenever you add a host to your environment (in the same datacenter), you will want to add it to DNS. Here is a list of steps that you need to take:

Primary Nameserver

Forward zone file: Add an "A" record for the new host, increment the value of "Serial"

Reverse zone file: Add a "PTR" record for the new host, increment the value of "Serial"

Configure New Host to Use Your DNS

Removing Host from DNS

If you remove a host from your environment or want to just take it out of DNS, just remove all the things that were added when you added the server to DNS (i.e. the reverse of the steps above).

Conclusion

Now you may refer to your servers' private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases maintenance.

Once you have your internal DNS set up, and your configuration files are using private FQDNs to specify network connections, it is critical that your DNS servers are properly maintained. If they both become unavailable, your services and applications that rely on them will cease to function properly. This is why it is recommended to set up your DNS with at least one secondary server, and to maintain working backups of all of them.