How to Setup Bind DNS Server in Chroot Jail on CentOS 7

bind dns

BIND (Berkeley Internet Name Daemon) also known as NAMED is the most widely used linux dns server in the internet.

This tutorial will explain how we can setup BIND DNS in a chroot jail in CentOS 7, the process is simply unable to see any part of the filesystem outside the jail. For example, in this post, i will configure BIND dns to run chrooted to the directory /var/named/chroot/.

Well, to BIND dns, the contents of this directory will appear to be /, the root directory. A “jail” is a software mechanism for limiting the ability of a process to access resources outside a very limited area, and it’s purposely to enhance the security.

Unlike with earlier versions of BIND, you typically will not need to compile named statically nor install shared libraries under the new root.

Chroot Environment initialization script will mount the above configuration files using the mount –bind command, so that you can manage the configuration outside this environment. There is no need to copy anything into the /var/named/chroot/ directory because it is mounted automatically. This simplifies maintenance since you do not need to take any special care of BIND configuration files if it is run in a chroot environment. You can organize everything as you would with BIND not running in a chroot environment.

Chrooted Bind DNS server was by default configured to /var/named/chroot. You may follow this complete steps to implement Bind Chroot DNS Server on CentOS 7 virtual private server (VPS).

See also  How to Install WebSVN for Subversion on CentOS

Setup Bind DNS Server in Chroot Jail on CentOS 7

1. Install Bind Chroot DNS server :

# yum install bind-chroot -y

2. To enable the named-chroot service, first check if the named service is running by issuing the following command:

# systemctl status named

If it is running, it must be disabled.
To disable named, issue the following commands as root:

# systemctl stop named
# systemctl disable named

3. Initialize the /var/named/chroot environment by running:

# /usr/libexec/setup-named-chroot.sh /var/named/chroot on
# systemctl stop named
# systemctl disable named
# systemctl start named-chroot
# systemctl enable named-chroot
ln -s '/usr/lib/systemd/system/named-chroot.service' '/etc/systemd/system/multi-user.target.wants/named-chroot.service'

The following directories are automatically mounted into the /var/named/chroot/ directory if the corresponding mount point directories underneath /var/named/chroot/ are empty:

Verify Chroot Environment :

# ll /var/named/chroot/etc
total 28
-rw-r--r-- 1 root root   372 Dec  1 23:04 localtime
drwxr-x--- 2 root named 4096 Nov 22 01:28 named
-rw-r----- 1 root named 1705 Mar 22  2016 named.conf
-rw-r--r-- 1 root named 2389 Nov 22 01:28 named.iscdlv.key
-rw-r----- 1 root named  931 Jun 21  2007 named.rfc1912.zones
-rw-r--r-- 1 root named  487 Jul 19  2010 named.root.key
drwxr-x--- 3 root named 4096 Jan  4 22:12 pki
# ll /var/named/chroot/var/named
total 32
drwxr-x--- 7 root  named 4096 Jan  4 22:12 chroot
drwxrwx--- 2 named named 4096 Nov 22 01:28 data
drwxrwx--- 2 named named 4096 Nov 22 01:28 dynamic
-rw-r----- 1 root  named 2076 Jan 28  2013 named.ca
-rw-r----- 1 root  named  152 Dec 15  2009 named.empty
-rw-r----- 1 root  named  152 Jun 21  2007 named.localhost
-rw-r----- 1 root  named  168 Dec 15  2009 named.loopback
drwxrwx--- 2 named named 4096 Nov 22 01:28 slaves

4. Create bind dns related files into chrooted directory :

# touch /var/named/chroot/var/named/data/cache_dump.db
# touch /var/named/chroot/var/named/data/named_stats.txt
# touch /var/named/chroot/var/named/data/named_mem_stats.txt
# touch /var/named/chroot/var/named/data/named.run
# mkdir /var/named/chroot/var/named/dynamic
# touch /var/named/chroot/var/named/dynamic/managed-keys.bind

5. Bind lock file should be writeable, therefore set the permission to make it writable as below :

# chmod -R 777 /var/named/chroot/var/named/data
# chmod -R 777 /var/named/chroot/var/named/dynamic

6. Copy /etc/named.conf chrooted bind config folder :

# cp -p /etc/named.conf /var/named/chroot/etc/named.conf

7.Configure main bind configuration in /etc/named.conf. Append the example.local zone information to the file :

# vi /var/named/chroot/etc/named.conf

Create forward and reverse zone into named.conf:

..
..
zone "example.local" {
    type master;
    file "example.local.zone";
};

zone "0.168.192.in-addr.arpa" IN {
        type master;
        file "192.168.0.zone";
};
..
..

Full named.conf configuration :

//
// 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 { any; };
        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     { any; };

        /*
         - 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
           recursion.
         - 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;
        dnssec-lookaside auto;

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

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

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

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "example.local" {
    type master;
    file "example.local.zone";
};

zone "0.168.192.in-addr.arpa" IN {
        type master;
        file "192.168.0.zone";
};

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

8. Create Forward and Reverse zone files for domain example.local.

See also  How to Fix "Could not reliably determine the server's fully qualified domain name"

a) Create Forward Zone :

# vi /var/named/chroot/var/named/example.local.zone

Add the following and save :

;
;       Addresses and other host information.
;
$TTL 86400
@       IN      SOA     example.local. hostmaster.example.local. (
                               2014101901      ; Serial
                               43200      ; Refresh
                               3600       ; Retry
                               3600000    ; Expire
                               2592000 )  ; Minimum

;       Define the nameservers and the mail servers

               IN      NS      ns1.example.local.
               IN      NS      ns2.example.local.
               IN      A       192.168.0.70
               IN      MX      10 mx.example.local.

centos7          IN      A       192.168.0.70
mx               IN      A       192.168.0.50
ns1              IN      A       192.168.0.70
ns2              IN      A       192.168.0.80

b) Create Reverse Zone :

# vi /var/named/chroot/var/named/192.168.0.zone
;
;       Addresses and other host information.
;
$TTL 86400
@       IN      SOA     example.local. hostmaster.example.local. (
                               2014101901      ; Serial
                               43200      ; Refresh
                               3600       ; Retry
                               3600000    ; Expire
                               2592000 )  ; Minimum

0.168.192.in-addr.arpa. IN      NS      centos7.example.local.

70.0.168.192.in-addr.arpa. IN PTR mx.example.local.
70.0.168.192.in-addr.arpa. IN PTR ns1.example.local.
80.0.168.192.in-addr.arpa. IN PTR ns2.example.local.

Bind dns related articles

See also  How to Install Cacti on CentOS 6.2 using EPEL Repository

Reference :
https://www.centos.org/docs/2/rhl-rg-en-7.2/ch-bind.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-bind.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html

Comments

4 Comments

  • Avatar Michael DeCamp says:

    Good instructions, but step number 2 (copy DNS files to the chroot environment) is incorrect for the current version of CentOS 7. In the current version (CentOS 3.10.0-514.2.2.el7.x86_64,, BIND 9.9.4-RedHat-9.9.4-38.el7_3) installing bind-chroot also installs the script /usr/libexec/setup-named-chroot.sh.

    This script is called by systemd when the service is started or stopped and dynamically mounts (umount) and unmounts the named.conf, pki files, and zone files into the chroot environment at run time. You can look at the top of the script to see which files are in scope. These files should be retained in their non-chroot locations.

    Realize that the documentation (https://www.isc.org/downloads/bind/doc/bind-9-9/, section 7.2.1) is not very clear, but that’s how the script actually works.

  • Avatar Michael DeCamp says:

    Better reference for how to install BIND in a chroot environment on CentOS:

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-BIND.html

    “If you have installed the bind-chroot package, the BIND service will run in the chroot environment. In that case, the initialization script will mount the above configuration files using the mount –bind command, so that you can manage the configuration outside this environment. There is no need to copy anything into the /var/named/chroot/ directory because it is mounted automatically. This simplifies maintenance since you do not need to take any special care of BIND configuration files if it is run in a chroot environment. You can organize everything as you would with BIND not running in a chroot environment.”

  • Avatar Peregrine says:

    There are several small problems with this article.

    1. The example “full” named.conf file is not a secure configuration, particularly if the server is accessible to the outside world. It seems that the author didn’t intend to cover that scenario however, it isn’t touched upon or specifically mentioned either way. I always assume that people are going to take the instructions I write and apply them to scenarios that expose the configuration to the outside world in as insecure a fashion as possible.

    2. Whenever you see “chmod 777″ that’s a giant red flag that something is not well understood. In the case of BIND, the particular files the author suggests we should apply mode 777 to are not likely to be accessible to anyone but root. Still, once again, it’s best to do this right. So, chmod g+sw /var/named/chroot/var/named/” before doing any other commands under that directory and the file and directory group ownerships will be the “named” group, automatically, when running those other commands. Then, do “chmod g+w” instead of “chmod 777” on those files. They definitely do NOT need execute bits and then certainly shouldn’t be readable or writable by everyone on the system.

    3. One must also fix a few permission bits and SELinux context labels on some of the touched files and directories one creates.

    4. In my case, the “/usr/libexec/setup-named-chroot.sh /var/named/chroot on” command appeared to run happily, but did nothing for me (I tried this on a few fresh, current, fully updated as of today CentOS 7 and RHEL 7 VMs). I ended up editing /etc/sysconfig/named file myself, creating all of the directories under /var/named/chroot/var/named/ manually (using ls -lZ on things under the /var/named/ directory to ensure I had all the permissions and labels matching), copying /var/named/named.* files into the /var/named/chroot/var/named/ directory and moving the /etc/named.* files into the /var/named/chroot/etc/ directory and creating symlinks to them in the /etc/ directory (a wise precaution against people editing the wrong files or thinking they’re missing). All important steps to get it working, almost none of which is covered.

    Even with these small problems, it only took me about 10 minutes to get BIND up and running (and securely so) on a CentOS 7 VM. I really appreciate this article. I’ve been running BIND servers on Linux system (SuSE, Red Hat, RHEL, CentOS, gentoo, etc.) since 1997, so I’m very familiar with it. The CentOS 7 variations on how to get it running under chroot make sense, once I got through it all, but certainly wasn’t something I think most people would “figure out” on their own. So, I say this article was quite helpful to me. I hope my little suggestions are useful to you and help other readers (especially those less familiar with BIND and/or Linux than I) to figure these things out.

    P.S. Before anyone complains that SELinux should “always be disabled”, you are flat out wrong. It’s not hard at all to make things work with SELinux, it adds a gigantically helpful security element (which only protects the system once someone has already broken in) and I’ve seen hundreds of people learn enough about SELinux to keep it on for every server with only 30 to 60 minutes of learning time. I don’t want to hear anyone griping to me that SELinux is “just always in the way”. I have my opinion and I respect that you have yours, so turn it off if you want, but don’t come crying to me WHEN (not IF) your servers are compromised and it results in the “bad guys” getting your data or using the server to attack others. SELinux is easy, once you know the right little bit about it. If you don’t want to, that’s your choice and I won’t try to talk you into changing your mind, so please don’t try to tell me that SELinux is bad and that I should stop using it. Thank you.

  • Avatar me says:

    I hope you get sued for that unexplained chmod 777 some day.
    Hopefully the chroot will always save you from your own mess, but you should not be posting howtos for anyone.

Leave a Reply

Your email address will not be published. Required fields are marked *