Modifications - Micetro - 26.1.0

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 to 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/.

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, such as 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 setups:

1. No views and all zones defined in default view (global scope)
2. 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.

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 an RP zone with the policy action override passthru is created or updated, it is added at the top of the response-policy stanza in the configuration. This is because passthru can be used to allowlist domains that occur in other RP zones. Meanwhile, RP zones with other overrides or without overrides are added at the bottom of the stanza.

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:

1. 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.
2. 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.

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.

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.