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).
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.
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
- How to Configure Bind-Chroot Logging on CentOS 6.2
- How to Install and Configure Bind9 DNS on Ubuntu 11.10
- How to Install and Configure Bind 9 as a Caching Server on Ubuntu 11.10
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
4 Comments
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.
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.”
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.
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.