ISC Consortium DHCP Server Release , which replaces the classic ISC DHCP. The project's source code is licensed under , instead of the previously used ISC License for ISC DHCP.
The Kea DHCP server is based on BIND 10 technologies and utilizes a modular architecture that breaks functionality into different handler processes. The product includes a fully functional server implementation supporting DHCPv4 and DHCPv6 protocols, capable of replacing ISC DHCP. Kea features built-in Dynamic DNS tools, supports server discovery mechanisms, address assignment, updates and reconnects, information request servicing, address reservation for hosts, and PXE booting. The DHCPv6 implementation also offers prefix delegation capabilities. A special API is provided for interaction with external applications, and configuration updates can be made on the fly without restarting the server.
Information about assigned addresses and client parameters can be stored in different types of repositories — currently, backends are provided for storage in CSV files, MySQL databases, Apache Cassandra, and PostgreSQL. Host reservation parameters can be specified in a configuration file in JSON format or in a table format in MySQL and PostgreSQL. Included is the perfdhcp tool for measuring DHCP server performance and components for collecting statistics. Kea shows good performance; for example, when using the MySQL backend, the server can execute 1000 address assignments per second (about 4000 packets per second), while using the memfile backend, performance can reach 7500 assignments per second.
Key in Kea 1.6:
- The backend configuration (CB, Configuration Backend) has been implemented, allowing for centralized management of the settings for multiple DHCPv4 and DHCPv6 servers. The backend can be used to store most Kea settings, including global parameters, common network information, subnets, options, pools, and option definitions. Instead of keeping all these settings in a local configuration file, they can now be stored in an external database. It is possible to define not all, but part of the settings via the CB, overlaying parameters from the external database and local configuration files (for example, network interface settings can be retained in local files).
Currently, only MySQL is supported as a backend database for configuration (for storing address assignments (leases), MySQL, PostgreSQL, and Cassandra can be used, while MySQL and PostgreSQL are used for host reservations). Configuration changes in the database can be made either through direct access to the database or through specially prepared wrapper libraries that provide a standard set of commands for managing the configuration, such as adding and removing parameters, bindings, DHCP options, and subnets;
- A new 'DROP' handler class has been added (all packets related to the DROP class are immediately discarded), which can be used to discard unwanted traffic, such as certain types of DHCP messages;
- New parameters max-lease-time and min-lease-time have been added, allowing the lease time of an address to a client (lease) to be defined not as a fixed value but as an acceptable range;
- Compatibility with devices that do not fully comply with DHCP standards has been improved. To work around these issues, Kea now sends the DHCPv4 message type information at the beginning of the options list, handles different representations of hostnames, recognizes the transmission of an empty hostname, and allows the definition of suboptions with codes from 0 to 255;
- A separate control socket has been added for the DDNS daemon, through which commands can be directly sent and configuration changes can be made. The following commands are supported: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown, and version-get;
- Fixed (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), which can be used to perform a denial of service (causing crashes of the server DHCPv4 and DHCPv6 handlers) by sending requests with invalid options and values. The most significant risk is the issue , which, when used for memfile storage bindings, leads to the server process being unable to restart on its own, hence manual intervention from an administrator is required to restore functionality (cleaning of the binding database).
Source: opennet.ru
