2

Named version: BIND 9.10.3-P4 (the latest one), OS versions: CentOS 6.3, CentOS 6.7

I need to use shared zones in different views, since 9.10 ISC Bind doesn't support using the same file for the same zone in different views. Trying to do so will lead to an error:

/etc/named.conf:21: writeable file 'slaves/example.db': already in use: /etc/named.conf:8

The documentation suggests using the in-view statement. Brandon Xavier in serverfault recommends the same. However, I failed. Here's simplified configuration file I'm trying to load:

view "internal" {

    zone example.com {
        type slave;
        file "slaves/example.db";
        masters { 192.168.1.1; };
    };

};

view "external" {

    zone example.com {
        in-view "internal";
    };

};

Removing the zone example.com from external view allows named to start. Configuring it to the separate file also works:

zone example.com {
    type slave;
    file "slaves/example2.db";
    masters { 192.168.1.1; };
};

But pointing to a different file is not an option - hereby I provide only example of real configuration. Also when Bind is trying to start, there's no output with an error message nor anything in logs:

# /etc/init.d/named restart
Stopping named:                                            [  OK  ]
Starting named: 
Error in named configuration:
                                                           [FAILED]

Isn't it just nice? Named-checkconf doesn't show any errors (I removed commas or brackets on purpose - checkconf works). I've also taken configuration files from 9.10.3-P4 sources.tar.gz (bin/test/system/..) and the result was the same. Should I report a bug?

  • Anything in the logs? I wouldn't count on getting the actual error in the output. Are you positive that this is the correct named version that you started? – Håkan Lindqvist Mar 18 '16 at 17:26
  • Sidenote: If you are not using in-view, then specifying different files is the only sane option for files that named will write for you (otherwise you are telling named to write multiple different zones to the same file) – Håkan Lindqvist Mar 18 '16 at 17:36
  • There're no errors in logs. I updated configuration with 'options' and 'logging' directives, but log-file is absolutely empty: pastebin.com/AHqN2QkW – Shader Mar 21 '16 at 6:08
  • Actually, the log string in /var/log/messages looks like "Mar 21 08:15:37 pDAUapp001Z1v named:", but in debug.log there's absolutely nothing. – Shader Mar 21 '16 at 6:16
  • Did logging work before you changed the logging config (ie, with it logging to syslog as per the defaults)? /var/log/debug.log seems like a potentially problematic path in terms of permissions (at least when rotating logs) when named is going to write to a file itself rather than just passing messages to syslog. – Håkan Lindqvist Mar 21 '16 at 6:44
2

Let's take a look on what /usr/sbin/named-checkconf does and returns. The man says: "named-checkconf returns an exit status of 1 if errors were detected and 0 otherwise".

Very well, let's write a script to check return values on a valid named configuration:

#!/bin/bash
/usr/sbin/named-checkconf -z /etc/named.conf >/dev/null 2>&1
echo $?
/usr/sbin/named-checkconf /etc/named.conf >/dev/null 2>&1
echo $?

The output will be 1 and 0. If we place an error in named.conf (e.g. missing semicolon), the results will be 1 and 1. What does it mean? It means the return code is 1 even if there're no errors in configuration but -z key is used - any output is considered as an error. Removing 2>&1 to leave only stderr doesn't have any effect, therefore the easiest temporary fix for this issue is to remove -z option by putting the following directive in /etc/sysconfig/named

DISABLE_ZONE_CHECKING="yes"

P.S. Running the above mentioned script on BIND 9.10.1-RedHat-9.10.1-0.el6 results 0 and 0 on a valid named configuration. And a conclusion: it's a bug in named-checkconf return values, when normal output results 1 return code. Bug with explanation, tests and configuration will be submitted to ISC.

NB! This solution is temporary until fix is implemented. Disabled zone checking won't find errors in zones, missing declaration files, etc. Disable it only if you use in-view directive.

| improve this answer | |
  • 4197. [bug] 'named-checkconf -z' didn't handle 'in-view' clauses. [RT #40603] handled in next maintainence release. – Shader Mar 23 '16 at 10:28
0

On CentOS 6 works without any problems

# ./named -v
BIND 9.10.3-P4 <id:ebd72b3>

# ./named -V
BIND 9.10.3-P4 <id:ebd72b3>
built by make with '--prefix=/opt/bind-9.10.3-P4' '--with-libtool' '--with-dlz-stub' '--with-dlz-filesystem' '--with-dlopen' '--without-idn'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-16)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20706

# ./rndc status
version: BIND 9.10.3-P4 <id:ebd72b3>
boot time: Mon, 21 Mar 2016 11:44:26 GMT
last configured: Mon, 21 Mar 2016 11:44:26 GMT
CPUs found: 4
worker threads: 4
UDP listeners per interface: 2
number of zones: 3
debug level: 3
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

P.S.

# lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.7 (Final)
Release:        6.7
Codename:       Final
| improve this answer | |
  • Yep, by default it works fine, I've checked it already. The failwhale comes when certain configuration with views and in-view statement is involved. Anyway I've found the source of the issue. Will post a solution with detailed explanation a bit later. – Shader Mar 21 '16 at 11:55
  • I have tested with your settings, which already include in-view statement – ALex_hha Mar 21 '16 at 12:05
  • Could you please share the full configuration file on pastebin? Thanks! – Shader Mar 21 '16 at 12:22
  • Here you go pastebin.com/KgutZdNz – ALex_hha Mar 21 '16 at 13:43
  • Awesome. This configurations fails to load with the same symptoms - no error messages, silent death. But if I do named -g for foreground run - everything works like a charm. I found the issue in init.d script and will post my solution after I recompile everything from sources (the troublesome package was installed from rpm from bkraft.fr). Anyway thank you for your help :) – Shader Mar 21 '16 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.