BIND10  20140306
DHCP Database Back-Ends

All DHCP lease data is stored in some form of database, the interface to this being through the Lease Manager.

All backend classes such as isc::dhcp::MySqlLeaseMgr are derived from the abstract isc::dhcp::LeaseMgr class. This provides methods to create, retrieve, modify and delete leases in the database.

There are currently two available Lease Managers, MySQL and Memfile:

  • The MySQL lease manager uses the freely available MySQL as its backend database. This is not included in BIND 10 DHCP by default: the --with-dhcp-mysql switch must be supplied to "configure" for support to be compiled into the software.
    • Memfile is an in-memory lease database, with (currently) nothing being written to persistent storage. The long-term plans for the backend do include the ability to store this on disk, but it is currently a low-priority item.

Instantiation of Lease Managers

A lease manager is instantiated through the LeaseMgrFactory class. This has three methods:

The selection of the Lease Manager (and thus the backend database) is controlled by the connection string passed to isc::dhcp::LeaseMgrFactory::create. This is a set of "keyword=value" pairs (no embedded spaces), each pair separated by a space from the others, e.g.

  type=mysql user=keatest password=keatest name=keatest host=localhost

The following keywords are used for all backends:

  • type - specifies the type of database backend. The following values for the type keyword are supported:
    • memfile - In-memory database. Nothing is written to any external storage, so this should not be used in production.
    • mysql - Use MySQL as the database

The following sections list the database-specific keywords:

MySQL connection string keywords

  • host - host on which the selected database is running. If not supplied, "localhost" is assumed.
  • name - name of the MySQL database to access. There is no default - this must always be supplied.
  • password - password for the selected user ID (see below). If not specified, no password is used.
  • user - database user ID under which the database is accessed. If not specified, no user ID is used - the database is assumed to be open.

Running Unit Tests

With the use of databases requiring separate authorisation, there are certain database-specific pre-requisites for successfully running the unit tests. These are listed in the following sections.


A database called keatest must be created. A database user, also called keatest (and with a password keatest) must also be created and be given full privileges in that database. The unit tests create the schema in the database before each test and delete it afterwards.

In detail, the steps to create the database and user are:

  1. Log into MySQL as root:
      % mysql -u root -p
      Enter password:

    1. Create the test database. This must be called "keatest":
        mysql> CREATE DATABASE keatest;

    2. Create the user under which the test client will connect to the database (the apostrophes around the words keatest and localhost are required):
        mysql> CREATE USER 'keatest'@'localhost' IDENTIFIED BY 'keatest';

    3. Grant the created user permissions to access the keatest database (again, the apostrophes around the words keatest and localhost are required):
        mysql> GRANT ALL ON keatest.* TO 'keatest'@'localhost';

    4. Exit MySQL:
        mysql> quit

The unit tests are run automatically when "make check" is executed (providing that BIND 10 has been build with the --with-dhcp-mysql switch (see the installation section in the BIND 10 Guide).