Basic Building Blocks: Setting up bind in CentOS 7 for DNS

featured image retrieved from

I had the chance to buckle down and get some DNS servers running in the lab. The process, although not painless, was not terribly difficult, and the upshot is that my lab is far more scalable than it was previously. I used a good guide that I found at Unixmen.

First, a primer on DNS. We all use DNS and we know that it provides name resolution against IP addresses, resulting in a far easier way to access our favorite servers than remembering a set of numbers. What do the core components of DNS do? I am going to assume you know what an IP address, host name, FQDN, etc. mean, so here’s a quick vocabulary list for us to get started:

  • Name server: this is a system running DNS server software and is intended to provide name resolution. DNS server software may include Microsoft’s built-in DNS server or something like BIND. Speaking of BIND…
  • BIND: Stands for Berkeley Internet Name Domain. This is the software package that I used for my DNS servers.
  • Zone files: Text documents that associate names to IP addresses (and vice versa). Zone files contain records (another term) which determine what sort of servers those IP addresses are resolving to. We’ll talk about specific types of records shortly.

Now that we know what we’re talking about, how do we go about setting up BIND? First, start with installing a minimal CentOS 7 image.


You’re going to want to do this twice, assuming that you want a primary and secondary DNS server. Read the Unixmen guide above for the differences in slave setup; if you’re able to set up a master DNS server you will have no problem setting up a slave. A primary server will be sufficient for some, but I plan on abusing these systems a bit down the line.

With CentOS installed and running, assign the systems static IP addresses and make sure that they can access the internet. The tool you want to use in a minimal install of CentOS 7 is nmtui.


OS installed, networking set up and blinking… let’s install bind!

sudo yum install bind bind-utils -y

After that’s done, we need to edit /etc/named.conf.

[aschenck@dns1 ~]$ sudo cat /etc/named.conf
// named.conf
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
// See /usr/share/doc/bind*/sample/ for example named configuration files.

options {
        listen-on port 53 {;;};
#       listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost;;};
        allow-transfer  { localhost;;};

         - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
         - If you are building a RECURSIVE (caching) DNS server, you need to enable
         - If your recursive DNS server has a public IP address, you MUST enable access
           control to limit queries to your legitimate users. Failing to do so will
           cause your server to become part of large scale DNS amplification
           attacks. Implementing BCP38 within your network would greatly
           reduce such attack surface
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/";
        session-keyfile "/run/named/session.key";

logging {
        channel default_debug {
                file "data/";
                severity dynamic;

zone "." IN {
        type hint;
        file "";

zone "vlab.local" IN {
        type master;
        file "forward.vlab";
        allow-update { none; };

zone "" IN {
        type master;
        file "reverse.vlab";
        allow-update { none; };

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";


Everything in bold needs to be edited, or in the case of the allow-transfer line, added. What we are telling named.conf to do is listen for DNS traffic on our IP and port, allow for anyone on our subnet to query for DNS information, and transfer zone files to any specified slaves. Finally, we need to add references to our forward and reverse zone files. Obviously, change things like “vlab.local” to whatever your own personal private domain happens to be.

With /etc/named.conf ready, we now need to create  our zone files, located at /var/named/.

Start with the forward zone file.

[aschenck@dns1 ~]$ sudo cat /var/named/forward.vlab
[sudo] password for aschenck:
$TTL 86400
@   IN  SOA    dns1.vlab.local. root.vlab.local. (
        00001       ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
@       IN  NS        dns1.vlab.local.
@       IN  NS        dns2.vlab.local.
@       IN  A
@       IN  A
@       IN  A
dns1           IN  A
dns2           IN  A
aveproxy       IN  A
[aschenck@dns1 ~]$


Now, what the heck does all of this mean? Let’s go through it line by line:

  • $TTL 86400 – This specifies the time to live. This is the amount of time in seconds after which a DNS client must discard an old record and grab an updated version.
  • IN SOA – “Internet Start of Authority”
  • dns1.vlab.local. – Primary master domain server.
  • root.vlab.local. – Email address of administrator for this zone. The . after root automatically becomes a @.
  • Serial – This is an arbitrary number that must be incremented every time you update the zone file so that it propagates correctly.
  • Refresh – Amount of time slaves will wait before polling the master for changes.
  • Retry – Amount of time a slave will wait before polling the master in case it is unreachable.
  • Expire – Amount of time a slave will wait before no longer returning DNS results as authoritative in case of master failure.
  • Minimum TTL – Amount of time that the name server will cache an error if it cannot find the requested name.

Finally, let’s talk about the record types found in the forward zone file:

  • NS records: These are name servers. Notice that we have NS records for both dns1.vlab.local as well as dns2.vlab.local.
  • A records: These map a host to an IPv4 addresses. Notice I have records for three hosts, including the already-mentioned dns1 and dns2 hosts.

Our reverse zone file looks similar, but serves a different purpose. Forward lookups resolve hostnames to IP addresses; reverse lookups associate IP addresses to hostnames!

[aschenck@dns1 ~]$ sudo cat /var/named/reverse.vlab
[sudo] password for aschenck:
$TTL 86400
@   IN  SOA    dns1.vlab.local. root.vlab.local. (
        2011071001  ;Serial
        3600        ;Refresh
        1800        ;Retry
        604800      ;Expire
        86400       ;Minimum TTL
@       IN  NS        dns1.vlab.local.
@       IN  NS        dns2.vlab.local.
@       IN  PTR       vlab.local.
dns1        IN  A
dns2        IN  A
aveproxy    IN  A
2       IN  PTR       dns1.vlab.local.
3       IN  PTR       dns2.vlab.local.
175     IN  PTR       aveproxy.vlab.local.
[aschenck@dns1 ~]$

As you can see, the beginning of these files are the same, but now we introduce PTR (pointer) records. PTR records do the bulk of work when it comes to reverse DNS lookups.

With our zone files created, we can now enable and start the DNS service on CentOS, as well as poking the appropriate hole through the firewall.

systemctl enable named
systemctl start named
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

Just a few more things to do… change the group of /var/named to named, change the owner and group of /etc/named.conf, and tell SELinux about the new defaults for /var/named as well as /etc/named.conf.

chgrp named -R /var/named
chown -v root:named /etc/named.conf
restorecon -rv /var/named
restorecon /etc/named.conf

The last thing you need to do, assuming all is well, is go back into nmtui and change your DNS IP to your DNS server’s static ip address!

Now, the moment of truth… let’s test our DNS server using dig.

[aschenck@dns1 ~]$ dig

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58864
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

; EDNS: version: 0, flags:; udp: 4096
;                    IN      A

;; ANSWER SECTION:             300     IN      A

;; AUTHORITY SECTION:             148671  IN      NS             148671  IN      NS             148671  IN      NS             148671  IN      NS

;; ADDITIONAL SECTION:         148671  IN      A         148671  IN      A         148671  IN      A         148671  IN      A

;; Query time: 260 msec
;; WHEN: Mon Dec 21 18:37:13 EST 2015
;; MSG SIZE  rcvd: 191

[aschenck@dns1 ~]$

If you get similar output to what you see above, and your “SERVER” output is your DNS server’s IP address, you’re all set and you can start using your DNS server to resolve names on your lab’s network.

Now that DNS is up and running, I have been able to install the Avamar image proxy on my machine without any problems 🙂 We’ll go over Avamar in a future post.


Things learned today: take the time to set up basic services like DNS as opposed to relying on your consumer router to do it for you. It’s a lot less frustrating to get it set up correctly and then have a dedicated VM to serve your lab than it is to fight with a router that’s marketed towards people who would have zero clue what a pointer record or zone file is!


A little prep goes a long way: thoughts on basic services for a home lab


Image credit:

What’s the saying? “If you find yourself in a hole, the first step is to stop digging.” Sage advice, assuming you follow it, and I’m guilty of not following my own advice.

As I continue to build my lab up, I am finding it increasingly difficult to scale. I am already up to nine VMs and it’s becoming a challenge to manage all of the different DNS names and IPs. Part of the problem is that my router, an ASUS RT-AC68U, is acting as both a DNS and a DHCP server for everything, lab and home network included. While it has worked very well for me as a standard home router and has provided excellent 802.11ac coverage, it is not really well equipped to do things like record editing and manual forward/reverse lookup changes.

In the back of my mind, I knew that this problem was a ticking time bomb. Sooner or later, the inability for me to edit DNS settings before creating it was going to rear its ugly head, and sure enough, today was the day it decided to do so.

I managed to successfully install EMC Avamar Virtual Edition on my lab (hooray! also, I’ll post about this soon!) and I am preparing to do image-level, proxy-driven backups of a couple of VMs. The problem that I am encountering, however, is that Avamar isn’t recognizing the DNS names of the proxy that I am attempting to create as there are no A records to reference, and it won’t let me fix the problem after installation as it will just uninstall the proxy at the first sign of trouble. Clearly, this just won’t do.

The short-term fix, which I will be working on deploying soon, is to deploy a system that acts as a DNS server for my lab. Thankfully I have a ton of different options to do this.

  1. Linux is an obvious choice. DNS is not exactly a high-stress service that requires a lot of power, so it may make sense to deploy a standard CentOS 7 server from a template, load up the dns server, and point all new lab clients to that server for future use. has an excellent writeup on the matter.
  2. There’s another, perhaps more interesting option: pfSense. pfSense is a FreeBSD-based open source firewall/router that a lot of home labbers like to throw around as a good services OS. Again, this would be a low-impact VM, and I don’t mind using something outside of Linux if it makes sense and is purpose-built.

I’ll likely deploy this either tomorrow or over the weekend, but for now, here are my thoughts for future lab builds to make life a little easier:

  1. Start with a plan. It doesn’t have to be a great plan and it can just be a sheet of notebook paper that you quickly sketched out, but don’t just deploy ESXi, throw VMs on top of it, and hope for the best. Have some sort of hierarchy. Will you be using a separate subnet outside of your home network? Will you be deploying VLANs? What will you do for separate physical devices, such as routers, hosts, etc.?
  2. Use Excel or Google Docs to keep track of your VM name, DNS name, IP settings, and so forth. Again, this doesn’t need to be fancy, but you’ll thank yourself down the line. It’ll make troubleshooting and merely expanding your lab so much easier in the future.
  3. If you have access to Visio, use that to diagram your lab as it grows. A visual representation of your lab will go hand in hand with your spreadsheet in both troubleshooting and expanding.
  4. If your lab is going to grow beyond a few VMs (and environments like mine are pretty much guaranteed to do so!), spend time deploying service VMs. DHCP and DNS should absolutely be part of this, and if you are planning on doing anything with Active Directory, plan on doing that as well.
    1. By extension, that means you should also plan on deploying app servers such as SQL as well, if you forsee the need for them!


For my next post, I’ll spend a little time on deploying pfSense and reviewing DNS, and then we’ll talk about Avamar Virtual Edition and why it’s absolutely awesome.