Can't start Bind open: /etc/named.conf: permission denied

Question

so I'm really new on this and was following this tutorial to set up bind, and up to 4:50 I was having no problems, I could ping, use nslookup and had internet connection with the dns server, then we had to add the zones and create the zone files (just creating them), perfect, I restart to see if there's any trouble (I use a virtual machine btw), then i could no longer ping, use nslookup and i didn't even have internet connection. This is what I got using systemctl status

Redirecting to /bin/systemctl status  -l named.service
● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor prese$
   Active: failed (Result: exit-code) since jue 2019-04-25 23:14:30 -04; 3min 3$
  Process: 3355 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "y$

abr 25 23:14:30 linux bash[3355]: _default/0.168.192.in-addr.arpa/IN: bad zone
abr 25 23:14:30 linux bash[3355]: zone localhost.localdomain/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone localhost/IN: loaded serial 0
abr 25 23:14:30 linux bash[3355]: zone 
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.$
abr 25 23:14:30 linux bash[3355]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial$
abr 25 23:14:30 linux bash[3355]: zone 0.in-addr.arpa/IN: loaded serial 0
abr 25 23:14:30 linux systemd[1]: named.service: control process exited, code=e$
abr 25 23:14:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain$
abr 25 23:14:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:14:30 linux systemd[1]: named.service failed.

I thought this was because of the empty zone files so I replaced with a named.conf without the zones, tried to restart with service restart named but got (again):

Failed to start BIND : Redirecting to /bin/systemctl start named.service Job 
for named.service failed because the control process exited with error code.
See "systemctl status named.service" and "journalctl -xe" for details.

So I did

● named.service - Berkeley Internet Name Domain (DNS)
 Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since jue 2019-04-25 23:25:30 -04; 1min 3s ago
  Process: 5557 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=1/FAILURE)
  Process: 5552 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS)

abr 25 23:25:30 linux named[5559]: found 2 CPUs, using 2 worker threads
abr 25 23:25:30 linux named[5559]: using 2 UDP listeners per interface
abr 25 23:25:30 linux named[5559]: using up to 21000 sockets
abr 25 23:25:30 linux named[5559]: loading configuration from '/etc/named.conf'
abr 25 23:25:30 linux named[5559]: open: /etc/named.conf: permission denied
abr 25 23:25:30 linux named[5559]: loading configuration: permission denied
abr 25 23:25:30 linux systemd[1]: named.service: control process exited, code=exited status=1
abr 25 23:25:30 linux systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
abr 25 23:25:30 linux systemd[1]: Unit named.service entered failed state.
abr 25 23:25:30 linux systemd[1]: named.service failed.

It's a permission problem but it worked perfectly before so I'm at a loss.

This is what I get by doing ls -l /etc/named.conf :

-rw-r-----. 1 root root 1808 abr 25 15:13 /etc/named.conf

And this is when I do ls -Z /etc/named.conf (if it has something to do with selinux):

 -rw-r-----. 1 root root unconfined_u:object_r:etc_t:s0 /etc/named.conf

Not sure if it helps but here's the named.conf

options {
    listen-on port 53 { 127.0.0.1; };
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        allow-query     { localhost; };

    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/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";
};

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

I also don't have a chroot folder in /etc/named/
Is there a solution for this? Thanks.

Answer 1

when I replaced the named.conf the selinux context got messed, when doing ls -Z it should look like this

-rw-r--r--. root root system_u:object_r:named_conf_t:s0 named.conf

As you can see mine it's different, to reset it, I used

restorecon -RFv /etc/named.conf

With this, however, doing ls -Z gave me this

-rw-r-----. root root system_u:object_r:named_conf_t:s0 named.conf

To add the last 'r' so everyone can read it, I did

chmod 644 /etc/named.conf

Stopped the service named and restarted it, and it works again.

Answer 2

On CentOS 7 bind runs by default as named user, not root, hence it cannot read your named.conf, as it is owned by root and readable by root only.

As Håkan Lindqvist already commented, the permissions on CentOS 7 should look like below:

-rw-r-----. 1 root named 10672 04-09 20:02 /etc/named.conf

so do:

# chown root:named /etc/named.conf
# chroot 640 /etc/named.conf

Answer 3

I had a similar problem with some new scripts that push updates out to local machines. These commands will run as "named" and allow you see some simple responses:

runuser -u named -- /usr/sbin/named-checkconf -z /etc/named.conf runuser -u named -- /usr/sbin/named-checkzone mydomain.internal /var/named/chroot/var/named/internal/mydomain.internal runuser -u named -- /usr/bin/ls -l /var/named/chroot/var/named/internal/

You can change the paths as necessary.

Answer 4

I would request you to check audit logs, and if you are using any additional filesystem acl check those logs too, If you think this is SELinux issue please disable and try it again if it works you need to fix selinux policies. please check https://www.systutorials.com/docs/linux/man/8-bind_selinux/ for bind selinux reference.

Answer 5

Ditto here: but with Debian 10, ISC Bind 9.11.5.

Pre-checklist

I provide a checklist to ensure that the rest of the message does not apply, you might want to check in the following directories for any errant PID path configuration settings for Bind9/named.

• /etc/default/named (or /etc/default/bind9) for PIDFILE=
• /etc/named/named.conf (or any include config files) for pid-file=
• /etc/systemd/system/bind9.conf for PIDfile=

Details, Details, Details

Once above checklist is done... you can go to the end of this TL;DR to the Workaround section for THE instant solution.

The partial error log message "couldn't mkdir" is found only in bind9/named/unix/os.c source file: Closest line link is in ISC Bind9 Github.

After perusing the source code for mkdirpath() usage and ascertained that mkdirpath() is used only within bind9/named/unix/os.c source code, I've gathered that ISC developer(s) hasn't co-opted the newer 'non-root' group file permission protection method ... yet as the code is still hardcoded for named daemon to be running only as 'root' group and not in 'bind' (or 'named') group ... yet.

This is particularily true on Debian when running tmpfiles daemon (via systemctl start tmpfilesd) where the control of /var/run (or more accurately, /run) is being controlled by the tmpfiles daemon (and not by named daemon).

My named daemon CLI options has that -u bind option which is conflicting with the hardcoded 'root'.

We know that named_os_issingleton() is not the caller of mkdirpath() because the log output is missing that 2nd error log "couldn't create:...".

This leaves us with the lone caller of named_os_openfile() calling `mkdirpath()'. And it is called in two places:

• server.c (to dump the key into a key file)
• os.c (to write a PID file)

We know it's not server.c because there is no 2nd error message either in our log file.

At this point, we can only surmise it is having trouble writing a PID file. I'm not surprise that Debian as decided to knock off the /var portion from its usual /var/run/named.pid. It's to be expected given the newst Linux Filesystem Standard 3.0, gritty details here.

Like you, I too have changed this PID file directory from '/run/named' to '/run/bind' (or more accurately, '/run/bind-public' because I'm running multiple named daemon in bastion-host configuration mode). And SOMEONE is still stuck on named as a sub-directory name, even though we changed it to bind.

At the moment, manual traceback so far is:

• mkdirpath()
• named_os_openfile()
• named_os_writepidfile()

Re-reviewing the server.c, you will noticed that named_g_defaultpidfile define is hardcoded to "/run/named", despite our best effort to reconfigure that to something else. It is defined in globals.h (here).

Workaround

Workaround is to ... create a subdirectory /run/named to fake out ISC bind code during startup

   mkdir /run/named
   chown root:bind /run/named
   chmod u+rwx,g+rx-w,o-rwx /run/named

and to 'ignore it' for now.

But .... also, if you're running tmpfiles daemon at startup, you will probably instead have to do this to /etc/tmpfiles.d/named.conf (or bind.conf or in my case, /etc/tmpfiles.d/bind-public.conf):

#Type Path                 Mode User Group Age Argument

# We set the 2xxx part (g+s) of directories' chmod so
# that when the named/bind9 daemon creates 
# that PID file, its ownership would be bind:bind.
d  /run/bind           2770 root bind  - -

# Add the following line to suppress spurious log message    
d  /run/named          0750 root bind  - -

Once made, pesky log gone.