Bug 9278

Summary:	bind as provided won't even start
Product:	Mageia	Reporter:	Frank Griffin <ftg>
Component:	RPM Packages	Assignee:	Guillaume Rousse <guillomovitch>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	davidwhodgins
Version:	Cauldron
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	bind	CVE:
Status comment:
Attachments:	Patch for /etc/named.conf

Description Frank Griffin 2013-03-06 23:01:39 CET

I may be way off base here, but ...

I'm rebuilding my firewall system.  That system runs a bind DNS server and a DHCP server.  I haven't done this for a couple of years, so obviously bind has changed a bit in that time.

I expected that.  I have to modify named.conf to include the source files for my LAN subnet and forwarder information for my ISP's DNS servers for everything else.

However, as installed, the /etc/named.conf from the bind package refers to a whole bunch of files that bind looks for in the /var/lib/named chroot which simply don't exist.  And named-checkconf doesn't like this.

Examples are a bunch of named.xxx files, such as named.localhost, named.loopback, and so forth which are named in the named.conf as database files backing the various zones defined in named.conf.  Among these is named.ca, which is supposed to be the list of root servers.

Also, named.conf refers to a logging file with a relative path of data/named.run.  Not only does the file not exist, the data directory hasn't been created either.

I got this to work eventually by going through my old firewall bind configuration and figuring out a mapping from the names used there to the names used in the new named.conf.  But the fact is, all of those files were provided by the bind package I installed when I last built the firewall, and they're not there now.

Anybody setting up a bind server ought to know what they're doing, but the package we provide, *whatever* it's configured to do, should at least start the server correctly out-of-the-box for whatever that is.  It's not reasonable to require bind users to have to figure out what you really wanted in named.localhost or named.empty.


Reproducible: 

Steps to Reproduce:

Manuel Hiebel 2013-03-09 11:54:58 CET

Assignee: bugsquad => guillomovitch

Comment 1 Dave Hodgins 2013-03-09 23:47:59 CET

[root@test ~]# urpmi bind
    http://192.168.10.101/distrib/cauldron/x86_64/media/core/release/bind-9.9.2.P1-5.mga3.x86_64.rpm
installing bind-9.9.2.P1-5.mga3.x86_64.rpm from /var/cache/urpmi/rpms                                            
Preparing...                     ###############################################################################
      1/1: bind                  ###############################################################################
[root@test ~]# systemctl start named.service
[root@test ~]# nslookup mageia.org 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   mageia.org
Address: 217.70.188.116

Looks like it's working to me.

CC: (none) => davidwhodgins

Comment 2 Frank Griffin 2013-03-10 00:00:49 CET

Could you check your /etc/named.conf, and see if it references a bunch of named.*** files, and if, in fact, they exist ?

Comment 3 Dave Hodgins 2013-03-10 21:46:40 CET

Created attachment 3598 [details]
Patch for /etc/named.conf

While it doesn't seem to stop named from working, the named.conf does specify
files that are not found. such as named.localhost.

When /lib/systemd/system/named.service runs /usr/sbin/setup-named-chroot.sh,
/var/named, which contains named.localhost is bind mounted to
/var/lib/named/var/named.

As /var/lib/named/etc/named.conf (bind mounted from /etc/named.conf) references
file "named.localhost";, named will (as I understand it) be looking for
/var/lib/named/named.localhost, not /var/lib/named/var/named/named.localhost.

In /etc/named.conf, I think 'file "named.localhost";' should be changed to
file "/var/named/named.localhost";

Comment 4 Frank Griffin 2013-03-11 00:06:29 CET

I should have mentioned that the system I'm running this on is at *secure* level.  That may account for why named-checkconf is run (and fails because of the missing files) at bind startup, and prevents bind from starting.

And, at least in *secure*, the chroot under which "named.localhost" is looked for is /var/lib/named/var/named.  That's where I had to put the missing files to pass the named-checkconf tests.

If desired, I can attach the files I copied from an older version that got things working.  I did make one change to named.conf.  As installed from cauldron, named.conf made the localhost zones specific to 127.0.0.1 and 1::0...0...  In the older files I copied forward, those zones were opened to 127.0.0.x and 0::0...

Comment 5 Guillaume Rousse 2013-03-13 20:00:26 CET

The configuration patch won't change much, as file location in bind configuration is computed relatively to the 'directory' directive if not starting with a / character.

All the files referenced by the default named configuration files are installed under /var/named (on the actual filesystem), and automatically bind mounted inside the /var/lib/named chroot when running /usr/sbin/setup-named-chroot.sh script. If you run named-checkconf with the -t argument, without actually populating the chroot through the script, a failure is indeed expectable.

That's also true for the data directory: it is created by package installation as /var/named/data, and then bind mounted in the chroot when starting the service.

This is indeed quite different from previous setup, where all files where actually installed directly within the chroot. I suspect some file upgrade issue in your case, as you're mentionning updating from an earlier version. Or an issue with hardcoded file locations in msec configuration files, as you also mention a specific security level.

Status: NEW => ASSIGNED

Comment 6 Frank Griffin 2013-03-13 21:10:28 CET

(In reply to Guillaume Rousse from comment #5)
> 
> This is indeed quite different from previous setup, where all files where
> actually installed directly within the chroot. I suspect some file upgrade
> issue in your case, as you're mentionning updating from an earlier version.
> Or an issue with hardcoded file locations in msec configuration files, as
> you also mention a specific security level.

No, there's no update involved.  This is a fresh install, but I migrated the database files from an older one, and created the missing files from their older counterparts.

The named.service file has:

ExecStartPre=/usr/sbin/setup-named-chroot.sh /var/lib/named on
ExecStartPre=/usr/sbin/named-checkconf -t /var/lib/named -z /etc/named.conf
ExecStart=/usr/sbin/named -u named -t /var/lib/named $OPTIONS

That's where the named-checkconf comes from.

Comment 7 Guillaume Rousse 2013-03-13 21:30:47 CET

Indeed, I missed it. If that's a fresh install, can you check the output of rpm --verify bind ? It should protest about missing files.

Comment 8 Frank Griffin 2013-03-14 01:24:41 CET

I'm not sure about the integrity of this, given that I've supplied the missing files, but :

[root@ftgfw ftg]# rpm --verify bind
S.5....T.  c /etc/named.conf
S.5....T.  c /etc/rndc.key
.....UG..    /var/lib/named/var/named
[root@ftgfw ftg]# 

I can check this in a fresh system if you like.  The aim of this exercise is to update a post-install set of scripts which customize the firewall system and several VBox VMs which run on it so that they are pretty much turnkey installs (until the next time package changes break them, anyway :-) ), so I have a few more iterations of starting from scratch to go, and I can easily do tests on a vanilla install before the scripts run.

Comment 9 Guillaume Rousse 2013-03-17 20:09:28 CET

I just installed it myself on a fresh system, I couldn't reproduce the issue.

Comment 10 Frank Griffin 2013-03-18 00:40:38 CET

Interesting.  I'll run a full reinstall tomorrow, but stop before my post-install script.

When you say you couldn't reproduce the issue, exactly what is your test case ?  I'd assume it's starting bind successfully in a *secure* system profile, but I'd like to be sure we're on the same page here.

Comment 11 Guillaume Rousse 2013-03-18 09:38:03 CET

As said earlier, if your problem comes from a msec or an installer setting, you'd better report it as an msec or installer bug, as the problem doesn't come from bind package. It's not just "not my problem", rather than I have no clue what they do and how they are configurable.

Comment 12 Frank Griffin 2013-03-20 15:43:26 CET

I re-did the fresh install in a VM.  The install itself does not install bind, and both prior to (checked from rescue) and after the first boot, no /var/lib/named directory existed (as expected).

I then disabled msec, and installed bind, but did not start it.  At that point, /var/lib/named and its subdirectories had been created by the rpm install, but none of the files were present:

********************************************************
[root@localhost ftg]# cd /var/lib/named
[root@localhost named]# ls -lR
.:
total 16
drwxr-xr-x 2 root root 4096 Mar 20 10:16 dev/
drwxr-xr-x 4 root root 4096 Mar 20 10:16 etc/
drwxr-xr-x 3 root root 4096 Mar 20 10:16 usr/
drwxr-xr-x 6 root root 4096 Mar 20 10:16 var/

./dev:
total 0
crw-r--r-- 1 root root 1, 3 Mar 20 10:16 null
crw-r--r-- 1 root root 1, 8 Mar 20 10:16 random
crw-r--r-- 1 root root 1, 5 Mar 20 10:16 zero

./etc:
total 12
-rw-r--r-- 1 root root 3519 Mar 20 10:16 localtime
drwxr-xr-x 2 root root 4096 Feb 26 13:16 named/
drwxr-xr-x 3 root root 4096 Mar 20 10:16 pki/

./etc/named:
total 0

./etc/pki:
total 4
drwxr-xr-x 2 root root 4096 Feb 26 13:16 dnssec-keys/

./etc/pki/dnssec-keys:
total 0

./usr:
total 4
drwxr-xr-x 4 root root 4096 Mar 20 10:16 lib64/

./usr/lib64:
total 8
drwxr-xr-x 2 root root 4096 Feb 26 13:16 bind/
drwxr-xr-x 2 root root 4096 Feb 26 13:16 openssl/

./usr/lib64/bind:
total 0

./usr/lib64/openssl:
total 0

./var:
total 16
drwxr-xr-x 2 named named 4096 Feb 26 13:16 log/
drwxr-xr-x 2 root  root  4096 Feb 26 13:16 named/
drwxr-xr-x 3 root  root  4096 Mar 20 10:16 run/
drwxr-xr-x 2 named named 4096 Feb 26 13:16 tmp/

./var/log:
total 0

./var/named:
total 0

./var/run:
total 4
drwxr-xr-x 2 named named 4096 Feb 26 13:16 named/

./var/run/named:
total 0

./var/tmp:
total 0
[root@localhost named]# 
*************************************************************


I then started bind, and it started fine.  Looking again at /var/lib/named:

**************************************************************
[root@localhost named]# ls -lR
.:
total 16
drwxr-xr-x 2 root root 4096 Mar 20 10:16 dev/
drwxr-xr-x 4 root root 4096 Mar 20 10:30 etc/
drwxr-xr-x 3 root root 4096 Mar 20 10:16 usr/
drwxr-xr-x 6 root root 4096 Mar 20 10:16 var/

./dev:
total 0
crw-r--r-- 1 root root 1, 3 Mar 20 10:16 null
crw-r--r-- 1 root root 1, 8 Mar 20 10:16 random
crw-r--r-- 1 root root 1, 5 Mar 20 10:16 zero

./etc:
total 28
-rw-r--r-- 1 root root  3519 Mar 20 10:16 localtime
drwxr-xr-x 2 root root  4096 Feb 26 13:16 named/
-rw-r--r-- 1 root root  1505 Feb 26 13:16 named.conf
-rw-r--r-- 1 root named 2389 Feb 26 13:16 named.iscdlv.key
-rw-r--r-- 1 root named  487 Feb 26 13:16 named.root.key
drwxr-xr-x 3 root root  4096 Mar 20 10:16 pki/
-rw-r----- 1 root named  259 Mar 20 10:16 rndc.key

./etc/named:
total 0

./etc/pki:
total 4
drwxr-xr-x 2 root root 4096 Feb 26 13:16 dnssec-keys/

./etc/pki/dnssec-keys:
total 0

./usr:
total 4
drwxr-xr-x 4 root root 4096 Mar 20 10:16 lib64/

./usr/lib64:
total 8
drwxr-xr-x 2 root root 4096 Feb 26 13:16 bind/
drwxr-xr-x 3 root root 4096 Mar 20 09:02 openssl/

./usr/lib64/bind:
total 0

./usr/lib64/openssl:
total 4
drwxr-xr-x 3 root root 4096 Mar 20 09:02 1.0.1e/

./usr/lib64/openssl/1.0.1e:
total 4
drwxr-xr-x 2 root root 4096 Mar 20 09:02 engines/

./usr/lib64/openssl/1.0.1e/engines:
total 312
-rwxr-xr-x 1 root root  20416 Feb 12 02:26 lib4758cca.so*
-rwxr-xr-x 1 root root  20680 Feb 12 02:26 libaep.so*
-rwxr-xr-x 1 root root  16328 Feb 12 02:26 libatalla.so*
-rwxr-xr-x 1 root root   6808 Feb 12 02:26 libcapi.so*
-rwxr-xr-x 1 root root  25192 Feb 12 02:26 libchil.so*
-rwxr-xr-x 1 root root  24776 Feb 12 02:26 libcswift.so*
-rwxr-xr-x 1 root root   6808 Feb 12 02:26 libgmp.so*
-rwxr-xr-x 1 root root 103152 Feb 12 02:26 libgost.so*
-rwxr-xr-x 1 root root  16232 Feb 12 02:26 libnuron.so*
-rwxr-xr-x 1 root root   6808 Feb 12 02:26 libpadlock.so*
-rwxr-xr-x 1 root root  24976 Feb 12 02:26 libsureware.so*
-rwxr-xr-x 1 root root  20608 Feb 12 02:26 libubsec.so*

./var:
total 16
drwxr-xr-x 2 named named 4096 Feb 26 13:16 log/
drwxr-xr-x 5 root  root  4096 Mar 20 10:16 named/
drwxr-xr-x 3 root  root  4096 Mar 20 10:16 run/
drwxr-xr-x 2 named named 4096 Feb 26 13:16 tmp/

./var/log:
total 0

./var/named:
total 28
drwxr-xr-x 2 named named 4096 Mar 20 10:30 data/
drwxr-xr-x 2 named named 4096 Mar 20 10:30 dynamic/
-rw-r--r-- 1 root  root  1892 Feb 26 13:16 named.ca
-rw-r--r-- 1 root  root   152 Feb 26 13:16 named.empty
-rw-r--r-- 1 root  root   152 Feb 26 13:16 named.localhost
-rw-r--r-- 1 root  root   168 Feb 26 13:16 named.loopback
drwxr-xr-x 2 named named 4096 Feb 26 13:16 slaves/

./var/named/data:
total 4
-rw-r--r-- 1 named named 1037 Mar 20 10:30 named.run

./var/named/dynamic:
total 8
-rw-r--r-- 1 named named 1227 Mar 20 10:30 managed-keys.bind
-rw-r--r-- 1 named named  512 Mar 20 10:30 managed-keys.bind.jnl

./var/named/slaves:
total 0

./var/run:
total 4
drwxr-xr-x 2 named named 4096 Mar 20 10:30 named/

./var/run/named:
total 8
-rw-r--r-- 1 named named   5 Mar 20 10:30 named.pid
-rw------- 1 named named 102 Mar 20 10:30 session.key

./var/tmp:
total 0
[root@localhost named]# 
**************************************************************

and this time:

**************************************************************
Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone localhost.localdomain/IN: loaded serial 0
Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone localhost/IN: loaded serial 0
Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Mar 20 10:30:01 localhost.localdomain named-checkconf[2919]: zone 0.in-addr.arpa/IN: loaded serial 0
Mar 20 10:30:01 localhost.localdomain named[2925]: starting BIND 9.9.2-P1 -u named -t /var/lib/named
**************************************************************

I'm closing this for now as INVALID.  I'll re-run the full install with my post-install script as soon as USB keyboards work again, and take it from there if the error recurs.  Sorry for the noise.

Status: ASSIGNED => RESOLVED
Resolution: (none) => INVALID