A module gets its configuration from the bind-cfgd daemon.

Upon startup, the module connects to the command&control channel, and sends his Data Specification to the configuration daemon. This specification is stored in a .spec file, and contains the format of the configuration data, and the direct commands the module accepts from other parts of BIND 10. The syntax is described in DataElementDesign. The module then asks the configuration daemon for existing configuration data, and configures itself with this data. If no configuration data is sets, defaults from the specification file are used.

When the configuration for this module is changed, the configuration daemon will send an update-config command, and the module updates itself according to the new configuration. If the update succeeds, the configuration daemon will store the new configuration.

Currently, only 'full' configurations are sent from the configuration daemon to the modules. Some form of diffs, or updates, are as of yet not implemented.

Message format

The data specification is sent to the configuration daemon directly, i.e. in the form of a map containing the single map element "data-specification", as read from the specification file.

The command to get all configuration for a specific module is { "command": [ "get_config", { "module_name" : "<module_name>" } ] }, to which the configuration daemon will respond with an answer of the form { "result" : [ 0, <Configuration> ] } or { "result" : [ <status code>, "<error message>" ] }.

On updates, the configuration manager will send a command to the module of the form { "config_update": <Configuration> }, to which the module will either reply with { "result": [0] } on success, or { "result": [ <status_code>: "<error" ] } if there is an error.


Modules don't need to take care of handling this messaging themselves. There is an API for this; CommandSession? (currently without namespace, and in src/bin/parkinglot/ccsession.h, but renaming and moving to isc namespace will be done shortly). The constructor takes a module name, a .spec file name, and two callback functions, one to handle config updates, and one to handle direct commands.

In general, there are two ways that the module can handle configuration. It could simply keep the Element structure that contains all the configuration around, and replace it if it gets a config_update command. Then when information is needed, it can read it directly from those Elements. This is the easiest solution in terms of implementation.

Though for critical paths, it might not be the most efficient solution. The other end of the spectrum is to create it's own optimal configuration structure, and update that structure when receiving new configuration data. In terms of access, this will improve things, at the cost of a more complicated configuration update handler. On the other hand, it would be wise to have a handler that checks whether the new configuration is valid anyway.

Last modified 8 years ago Last modified on Jan 27, 2010, 1:11:46 AM