Skip to end of metadata
Go to start of metadata

Symptom:

BIND 9 supports a feature called “Views”, whereby a single server can act as multiple different servers, giving different answers to queries depending on the source address of the query, the destination address of the query, or a TSIG key.
 
As of versions >= 5.0, the Men & Mice Suite also supports views. However, it does not (currently) offer a way to create views or edit view settings. Furthermore, Men & Mice DNS Server Controller requires that the configuration files be set up in a particular way.
 
This knowledge base article describes how to change from a configuration without views to a configuration with two views. Note that if views are set up before Men & Mice DNS Server Controller is installed, then the configuration files will already be set up correctly for those views.
 
This article is not intended to have a complete discussion of how views work, what options can be set in a view, etc. Please refer to the BIND 9 Administrator Reference Manual for this information.
 
One tricky part of setting up views is what to do with the root hints zone. Without views, this zone is declared in the user_after file, i.e. in a way different than other zones. However, with views, this is invalid - a zone (even the hint zone) may not appear outside of a view. Luckily, BIND 9 has a list of public root servers built in, so unless there is a need to define a different set of roots, the zone doesn’t need to be explicitly declared.
 
Note:
- The steps described in this article are relatively advanced, and it is assumed that the reader is sufficiently familiar with his server environment to operate as the root user as needed, to edit files, and to restart services. Proceed with caution. Explanations of the shell commands used can be found at the end of the article. 

Solution

 Setting up Views

File Layout

To make clear what the steps below are intended to accomplish, it’s useful to look at the differences between a configuration without views and one with views.
 
To start, locate the data directory used by named. This is usually something like one of the following:
/var/named
/var/lib/named
/var/chroot/named/var/named
/etc/namedb
However, it can be anywhere at all. If you’re not sure, look at named.conf. It should contain five include statements that import files in the conf subdirectory of the data directory. Where the instructions need to refer to this directory, it will be referred to as $NAMED, though such a shell variable probably does not exist on your server.
 
If views are not defined, the following files exist inside the data directory:
Description File(s) or Directory
A user-editable file that should contain at least the rndc key and may contain, among other things, the root hints zone declaration conf/user_after
List of include statements, one for each zone statement file conf/zones
Directory of zone statement files conf/zoneopt
A sample zone statement file, for the zone “localhost.” conf/zoneopt/localhost.opt
Directory of primary master zone files hosts/masters
Directory of slave zone files hosts/slaves
A sample zone file, for the zone “localhost.” hosts/masters/localhost-hosts


If views are defined, the following files should exist inside the data directory:
Description File(s) or Directory
A user-editable file that should contain at least the rndc key; may not contain the root hints zone declaration conf/user_after
View statements, not including zone statements within each view conf/zones
List of include statements for a particular view, one for each zone statement file conf/zones_viewname
Directory of zone statement files for a particular view conf/zo_viewname
A sample zone statement file, for the zone “localhost.” in the view “internal” conf/zo_internal/localhost.opt
Directory of primary master zone files for a particular view hosts/view_viewname/masters
Directory of slave zone files hosts/view_viewname/slaves


Moving Existing Zones To the First View

For the sake of example, these instructions will assume that any zones already defined should be moved into a view named external, and that a root hints zone is not needed for this view.
 
Before proceeding, if there are any disabled zones on the server, they should be enabled. Also, if there are any dynamic zones on the server, named should be stopped to avoid corruption of any journal files.
 
Execute the following shell commands:
cd $NAMED/hosts
mkdir view_external
mv masters slaves view_external
cd ../conf
mv zones zones_external
mv zoneopt zo_external
perl -pi -e 's {conf/zoneopt/} {conf/zo_external/}' zones_external
perl -pi -e 's {hosts/} {hosts/view_external/}' zo_external/*
Edit $NAMED/conf/user_after and remove the root hints zone declaration. It looks like this:
zone "." IN {
  type hint;
  file "conf/root.hint";
};
Create a new text file, $NAMED/conf/zones, with the following contents:
//
// File: zones
// Desc: This file should contain view statements, but not zone statements.
//       Each view statement should contain a match-clients statement,
//       any other desired view options, and then an include statement
//       referring to the file zones_viewname.
// NOTE: This file is never overwritten by Men & Mice Suite and can therefore
//       be edited by the user.
//
view "external" {
 match-clients { any; };
 include "conf/zones_external";
};
Next, you may need to set the ownership of all files appropriately with a command like this:
chown -R named:named $NAMED
The external view is now set up. Restart both named and Men & Mice DNS Server Controller (qdnsremoted), and then check the various log files for error messages.
 

Adding a New View

These instructions will describe how to add a view named internal to a configuration similar to what was created in the previous section.
 
Note: Views without zones is are not usable in M&M. The view will not show up in the Management Console. Therefore, these instructions will copy your existing zones into the new view.
 
Once again, before proceeding, if there are any dynamic zones on the server, named should be stopped to avoid corruption of any journal files.
 
Execute the following shell commands:
cd $NAMED/hosts
cp -R view_external view_internal
cd ../conf
cp zones_external zones_internal
cp -R zo_external zo_internal
perl -pi -e 's {conf/zo_external/} {conf/zo_internal/}' zones_internal
perl -pi -e 's {hosts/view_external/} {hosts/view_internal/}' zo_internal/*

Next, edit $NAMED/conf/zones and add a new view statement above the existing statement. This is because the existing view statement has a match-clients statement that matches all clients; views are tested in order, so more restricted view must appear before a more general view. The new statement should look something like this, assuming your internal network is 192.0.2/24:
view "internal" {
    match-clients { 192.0.2/24; };     include "conf/zones_internal";
};
The internal view is now set up. Restart both named and Men & Mice DNS Server Controller (qdnsremoted), and then check the various log files for error messages.
 

A Note About Zone Transfers

Using master zones with views is straightforward enough. And using a slave for one view or another is simple. But how can a slave server host both views of a zone?
 
The answer is, it must get two zone transfers, one for each version. When the slave server makes its zone transfer request, the request is compared against the various match- statements in the view, just as with a normal query. The important ones for a zone transfer request are match-clients and match-destinations. (The remaining match- statement, match-recursive-only, doesn’t apply to zone transfer requests.)
 
There are several ways to solve the problem:
 
The master server can have multiple IP interfaces, one for each view. Then the slave is told that its master server address for the zone is the appropriate interface for that view. This is a little tricky to set up, and it can be brittle.
The slave server can have multiple IP interfaces, one for each view. Then the master’s view statements have match-clients statements so that one of the slave’s interfaces is caught by one view, and the other interface goes to the other view. Again, this is a little tricky to set up and can be brittle.
Use TSIG keys. The master’s match-clients statement for each view should include the slave’s key for that view. This is straightforward to set up and maintain, and doesn’t require either server to have multiple IP interfaces. Please note that only the hmac-md5 algorithm is supported in the Men & Mice Suite.


Explanation Of Shell Commands

Here are explanations of the purpose of each shell command used above.
command description
cd $NAMED/hosts go to the hosts subdirectory of the data directory
mkdir view_external make a subdirectory for the new view’s zone files
mv masters slaves view_external move existing zone file directories into the new view
cd ../conf go to the conf subdirectory of the data directory
mv zones zones_external rename the existing list of zones for the new view
mv zoneopt zo_external rename the existing directory of zone statements for the new view
perl -pi -e ‘s {conf/zoneopt/} {conf/zo_external/}’ zones_external fix the zone list for the new view
perl -pi -e ‘s {hosts/} {hosts/view_external/}’ zo_external/* fix the zone statements for the new view
   
chown -R named:named $NAMED fix the file ownership of the data directory and everything in it so that the named process owns all files
   
cd $NAMED/hosts go to the hosts subdirectory of the data directory
cp -R view_external view_internal make the zone file directory for the new view based on the first view
cd ../conf go to the conf subdirectory of the data directory
cp zones_external zones_internal make a zone list for the new view by copying the first view’s zone list
cp -R zo_external zo_internal make a zone statement subdirectory for the new view by copying the first view’s zone statement subdirectory
perl -pi -e ‘s {conf/zo_external/} {conf/zo_internal/}’ zones_internal fix the zone list for the new view
perl -pi -e ‘s {hosts/view_external/} {hosts/view_internal/}’ zo_internal/* fix the zone statements for the new view