"all zones must be in views", BIND 9 and You.

note: This article is intended for a technical audience -- you should use caution when modifying a production system -- caveat emptor.

An interesting question raised by a client, who was experiencing this error in their daemon.log file and asked me to track it down.

A bit of background:

The client in question runs a "Split Zone" configuration, where a seperate set of DNS entries are published to public users (that are only queried by and cannot be altered in any way by external entities) than are published to their other master or slave servers (which are secured by DNSSEC and various other access controls and can be queried by internal LAN users.)

So:

Apr 10 05:41:17 vampire named[8933]: loading configuration from '/etc/bind/named.conf'
Apr 10 05:41:18 vampire named[8933]: /etc/bind/named.conf:12: when using 'view' statements, all zones must be in views

has been in their logs for about six weeks since the server was commissioned and the new administrator wonders if that's the reason their zone information appears out of date?

Well, no.

First off, that message is not actually an error, it's a warning -- but it's still unsightly.

Second, the file it is complaining about is not /etc/bind/zonefiles/m/[name_of_zone].zone but /etc/bind/named.conf which happens to be the default configuration file for most common Linux distributions.

In fact, if you look at the Debian / Ubuntu configuration file you'll see:

"If you are just adding zones, please do that in /etc/bind/named.conf.local"

Which, in this case -- we did, using internal and external views that look a bit like:

view "internal-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { trusted; xfer; };
notify yes;
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { any; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { any; };
};
};

and:

view "external-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { any; };
notify yes;
recursion no;
additional-from-auth no;
additional-from-cache no;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { none; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { none; };
};
};

As you can see, we defined the root server hint file for both views, BIND 9.x gets rather tetchy if you don't do that, but will happily continue as long as you do (and, of course -- all your zones verify correctly with named-checkzone)

What, of course -- we failed to do was to define localhost, 127.in-addr.arpa, 0.in-addr.arpa and 255.in-addr.arpa for the internal and external view too.

The error goes away, as expected if you:

Firstly, Comment out the lines for the required zones in the /etc/bind/named.conf file. (Use '//' for commenting in this file)

Then, ammend your zone configuration to look similar to:

view "internal-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { trusted; xfer; };
notify yes;
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { any; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { any; };
};
};

and:

view "external-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { any; };
notify yes;
recursion no;
additional-from-auth no;
additional-from-cache no;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { none; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { none; };
};
};

Check your new configuration validates by running named-checkconf, then restart BIND the warning should vanish and your administrators should all go away satisfied.