BIND DNS File Structure

Note

The following reference article describes the BIND configuration file structure and process as applies to the current version of Micetro.

As of version 11.0, Micetro uses a parser to handle BIND configuration. The parser parses the configuration as a whole and patches only the portions that have been affected or changed. The parser maintains a list of all files included in the configuration, as well as the time at which each file was modified in order to detect whether the file was modified externally. This allows it to reload the configuration, if needed, or reject the modifications if there are potential conflicts.

As a result, it’s no longer necessary to manually arrange or change the configuration and it’s possible to implement read-only installation of the agents.

Installation

When Micetro is installed on a server running BIND, it needs to perform several changes to the server configuration file structure. This article describes these changes and includes an overview of how the server configuration files are processed after Micetro has updated the structure.

Arranging the Configuration and Files

When started, the parser detects the following:

Whether the directory <BWD>/conf/zones exists.
Whether the initial configuration file (typically named.conf) contains one of the following phrases:
- “// This file was generated by Men & Mice Suite”
  
  -or-
- “// This file was generated by Micetro”

If both of these criteria are met, the parser assumes that the configuration has been arranged and behaves accordingly.

Note

BWD is the BIND Working Directory, the location specified in the options directory statement. This value is usually /var/named/. If no directory statement is found, the current directory is assumed unless you specify the root directory (-r argument). If the root directory is specified, Micetro will assume relative to the root.

Additionally, if the configuration does not have a logging statement, the arranger adds a sensible logging statement, making it easier to adjust for different requirements and providing consistent logging across users.

named.conf

named.conf is split into several files. A new named.conf file that includes statements for all the new files is created.

When named.conf is split up, a new file is created for each zone statement (see Zone Options Files files, below).

Zone Options Files

A new file, <BWD>/conf/zones is created. It contains a list of includes for zone option files which are stored in the directory <BWD>/conf/zoneopt/, one for each zone. The zone options (or definitions) files are called <zonename>.opt.

Zone Files

No changes are made to the zone files themselves. The installer copies the zone files to different directories, depending on their types:

master and forward zones are copied to <BWD>/hosts/masters/
slave and stub zones are copied to <BWD>/hosts/slaves/

The new zone file is named <zonename>. If a zone is in a view, it will use the view name as a prefix, e.g., <viewname>-<zonename>.

Configuration Files

The configuration files are processed in the following order after the file structure has been updated by Micetro:

File: /etc/named.conf

include <BWD>/conf/logging

include <BWD>/conf/user_before

include <BWD>/conf/options

include <BWD>/conf/user_after

include <BWD>/conf/zones

Directory: <BWD>/conf

File: logging: Contains the logging statement.

File: user_before: Contains all ACL and key statement. It may not contain other statements.

Note

Micetro does not modify this file, so the user can change it, as needed.

File: options: Contains the options statement.

File: user_after: Contains the root.hint. zone statement. It can also contain controls, server, and trusted keys statements.

Note

Micetro does not modify this file, so the user can change it, as needed.

File: zones: Contains include statements for all zones on the server, e.g., include conf/zoneopt/text.com.opt.

Directory: <BWD>/conf/zoneopt

File: <zonename.opt>: Contains zone definition and options for <zonename>.

Example:

zone test.com. IN {
   type master;
   file hosts/masters/test.com;
   allow-query { any; };
};

Directory: <BWD>/hosts/masters

File: test.com: The actual zone file.

Communicating with BIND

While parsing the configuration, the parser checks whether an inet statement exists within the control statement. If an inet statement exists, the parser will use it to communicate with BIND. If it does not exist, however, the parser checks whether an rndc.conf or rndc.key file exists in the same directory as the initial configuration file (typically named.conf).

Note

It is preferred to use rndc.conf rather than rndc.key.

In the preferences.cfg, you do not need to explicitly define the location of named-checkconf and named-checkzone. The agent locates them automatically, given that they exist in a known default location. If desired, you can override this behavior by defining it in the preferences.cfg file. For information about specifying a different path for the named-checkconf and/or named-checkzone values, refer to Overriding the default named-checkconf or named-checkzone paths.

The following locations are searched in the following order:

/usr/local/bin
/usr/bin
/usr/sbin
/usr/local/sbin
/etc/local/sbin
/etc/opt/isc/isc-bind
/etc/opt/isc/scls/isc-bind

Modifications

Creating a Zone

When creating a zone, the parser creates the zone statement depending on the context:

If the zone is in a view: The view is the parent and the parser creates the zone statement as the last statement in the view (before the closing bracket).
If the zone is not in a view and you are in view setup: The parser finds a common include file and creates the zone statement there. The zone is created in the common include file and will appear in all views.
If an “old” arranged setup: The parser adds the zone statement to the zones file.
If none of the above: Add the zone statement in the main file.

The master file name will be [<view name>-]<zone name>. If there is a master file, the master file will be created in the BIND working directory under <BWD>/master/. Otherwise, it will be created under <BWD>/slave/. If this is an arranged configuration, the master file will be created in <BWD>/hosts/masters/ and other zone files will be created in <BWD>/hosts/slaves/.

Note

Illegal file name characters will be replaced by a hyphen.

Enabling or Disabling a Zone

When you enable a zone, the parser reads the zone statement from the file and adds it back to the configuration, the same way the zone was created.

When you disable a zone, the zone statement is saved to a file that is not included in the configuration and is then removed. The file containing the original zone statement is created in the directory <BWD>/conf/disabled_zones.

Information about all disabled zones — both names and needed zone properties, e.g., type — are kept in the file disabled_zones.json, which is located in the same directory as the preferences file.

Views

In BIND, you can have either of the following:

No views and all zones defined in default view (global scope)
View setup and all zones must be defined inside a view

Since BIND only matches one view (the first that matches), you may want to define the zones you want to have in some or all views in a separate configuration file and include the same file multiple times. Configuration files that are included in every view are called “common view includes” and the parser shows all zones defined therein as a single instance in the default view. When you create a zone in a default view, such as in a setup, the zone is created within the “common view includes” instead of creating a separate instance in all the views.

Response Policy Zones

When parsing the configuration, the parser searches for response-policy statements in both options and view statements. If the parser finds any reference to a zone, it marks the zone as an RP (response-policy) zone.

Note

If an RP zone is deleted, the parser removes the reference from the RP statements, since BIND will not load if the RP statements contain a reference to an unknown zone.

A zone becomes or ceases being an RP zone when its property is changed. When a zone becomes an RP zone, the parser adds a reference to an RP statement, depending on whether the zone is in or outside of a view (default view). If the zone is defined within a view, the parser adds a reference to the RP statement within the view or in the option statement. If the statement does not exist in the correct location, it is added to the RP statement.

When a zone ceases being an RP zone, the parser removes all reference to it, both inside the view and in the option statement, if applicable. This ensures that BIND will not fail to load.

Advanced Server Options

When prompted for advanced server options, the parser returns all the configuration files. However, an arranged configuration will only return the configuration files directly under <BWD>/conf.

Dynamic Zone and Key Handling

To determine whether a zone is a dynamic zone, the parser searches for two options:

allow-update: Can be defined in option, view, and zone scope level. However, according to the BINDv9Arm, this option should only be set at the zone level. Setting a default value at the options or view level may result in some zones allowing unintentional updates.
update-policy: Can only be defined in a zone scope.

A zone is considered dynamic if it is a primary zone with an allow-update statement defined the zone, view, or option statement (global scope) and the allow-update contains something other than “none”. A primary zone is also considered dynamic if it contains any update-policy statement.

Note

In Micetro, a dynamic property in a zone is a read-only property.

When updating a dynamic zone, the following occurs:

If allow-update is defined, the statement is “resolved” and if any localhost or localnets are found, it is assumed that update can occur without a key (unsigned). Otherwise, if a key can be found in the allow-update statement or any ACL it is using, that key will be used.
If update-policy is defined, the session-key is used for the update.

When transferring a zone:

If the zone is inside a view, the parser resolves the match-client statement and selects a key with the same name as the view or, if that key is not found, the first located key.

Note

“Resolving” an address match list (AML) means that if any reference to an ACL is found when parsing, the parser will read through them, as well.

When a zone changes from static to dynamic:

The parser makes sure that no previous journal files exist.

When a zone changes from dynamic to static:

The parser freezes or thaws the zone to make sure it can be updated.