Bind 9.10 in-view directive doesn’t work

binddomain-name-system

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?

Best Answer

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.

Related Topic