Kea, the ISC's successor to the DHCP daemon

Connecting

High Availability

Like the legacy dhcpd, Kea lets you set up a cluster of multiple servers. For this purpose, it needs the Lease Commands library to create leases on a partner server with the API and the HA library, which contains the information on how to reach the partner in its parameter block. When you set this up, you can use TLS or basic authentication to secure the connection between the cluster members.

You can either run the cluster in load-balancing mode to distribute the load or use hot-standby mode, in which only one Kea server is active at any given time. The configuration in Listing 9 shows the configuration for the load-balancing approach. You have the option of specifying which of the two servers you want to serve which pool in the address pool configuration. To do this, you need a line such as

Listing 9

HA with Load Balancing

"hooks-libraries": [{
 "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
 "parameters": {}
 }, {
 "library": "/usr/lib/kea/hooks/libdhcp_ha.so",
 "parameters": {
  "high-availability": [{
   "this-server-name": "server1",
   "mode": "load-balancing",
   "heartbeat-delay": 10000,
   "max-response-delay": 60000,
   "max-ack-delay": 5000,
   "max-unacked-clients": 5,
   "delayed-updates-limit": 100,
   "peers": [{
    "name": "server1",
    "url": "http://172.17.1.43:8000/",
    "role": "primary",
    "auto-failover": true
   }, {
    "name": "server2",
    "url": "http://172.17.1.44:8000/",
    "role": "secondary",
    "auto-failover": true
   }]
  }]
 }
}]

"client-class":"HA_server1"

in the configuration. The class here is automatically named HA_<Server-Name>.

In load-balancing mode, each of the two servers only issues addresses from its own pool. If one of the partners is not running, the other takes over. The other configuration parameters specify the times at which you want the system to check whether the other cluster members are still running and the frequency at which updates are distributed or how much backlog is allowed.

You can also combine your own class definitions with those provided by the load balancer. The Kea Administrator Reference Manual provides a how-to for this in the "Load Balancing with Advanced Classification" section [4].

DDNS

In many cases, you will want all of your hosts to have DNS records in addition to their IP addresses, both to resolve the name to the IP address (forward) and to resolve the IP to the name (reverse). To handle this operation, the legacy ISC dhcpd offered a function for sending DDNS updates from the assigned lease. Kea does not implement this function in the DHCP daemon, but provides its own kea-dhcp-dns service instead.

Like all the other services, you need to start and activate it separately. In addition to keys for authenticating updates, the matching configuration also contains information on the IP address and port combination on which the service accepts requests. Additionally, lists of DNS servers for forward and reverse zones let the service know to which servers it will send updates.

Listing 10 shows a simple configuration with only one key. Updates for one forward zone and one reverse zone are forwarded to the name server on host 172.17.1.1. For the reverse zone, an additional entry for a second name server demonstrates how the port parameter routes the connection to a different port.

Listing 10

DDNS Configuration

{
 "DhcpDdns": {
  "ip-address": "127.0.0.1",
  "port": 53001,
  "control-socket": {
   "socket-type": "unix",
   "socket-name": "/run/kea/kea-ddns-ctrl-socket"
  },
  "tsig-keys": [{
   "name": "dnstsigkey",
   "algorithm": "HMAC-MD5",
   "secret": "pjGqiQBjQUXELdUyP4lPzA=="
  }],
  "forward-ddns": {
   "ddns-domains": [{
    "comment": "Test Domain",
    "name": "demodomain.lmtest.de.",
    "key-name": "dnstsigkey",
    "dns-servers": [{
     "ip-address": "172.17.1.1"
    }]
   }]
  },
  "reverse-ddns": {
   "ddns-domains": [{
    "name": "6.17.172.in-addr.arpa.",
    "key-name": "dnstsigkey",
    "dns-servers": [{
     "ip-address": "172.17.1.1"
    }, {
    "ip-address": "192.168.77.88",
    "port": 53001
    }]
   }]
  },
  "loggers": [{
   // This specifies the logging for D2 (DHCP-DDNS)
 daemon.
   "name": "kea-dhcp-ddns",
   "output_options": [{
    "output": "@localstatedir@/log/kea/kea-ddns.log"
   }],
   "severity": "INFO",
   "debuglevel": 0
  }]
 }
}

Further configuration is needed on the DHCP server to make it use the DDNS server. Make sure the entry in the name field ends with a period for forward domains. From the configuration in Listings 10 and 11, it follows that the DHCP server sends a DNS update request for name.demodomain.lmtest.de. , even without a dot at the end of the domain in the dhcpd configuration. It took me about half an hour of searching to realize this.

The configuration block in Listing 11 tells Kea to set the hostname to prefix-172-17-6-6.demodomain.lmtest.de if the client does not send its own name. You can also populate the statement in ddns-replace-client-name with the values when-present, always, or never. In addition to the A and PTR records, the simple dynamic DNS daemon (ddnsd) also creates a DHCP client ID (DHCID) record in the forward and reverse zones. If a DHCP client releases its lease correctly, the entries are deleted.

Listing 11

Adding DHCP for DDNS

"dhcp-ddns": {
 "enable-updates": true,
 "server-ip": "127.0.0.1",
 "server-port": 53001,
 "sender-ip": "127.0.0.1",
 "max-queue-size": 2048,
 "ncr-protocol": "UDP",
 "ncr-format": "JSON"
},
"ddns-send-updates": true,
"ddns-override-no-update": true,
"ddns-override-client-update": true,
"ddns-replace-client-name": "when-not-present",
"ddns-generated-prefix": }, "prefix",
"ddns-qualifying-suffix": "demodomain.lmtest.de",
"ddns-update-on-renew": false,
"ddns-use-conflict-resolution": true,
}, "hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x",

Migration

Kea completely replaces the legacy dhcpd. In more complex configurations that contain many reservations and that use files with hundreds or thousands of lines, manual conversion would be very time consuming and extremely prone to error. This problem prompted the ISC to provide the keama tool, which creates a Kea DHCP configuration from a dhcpd.conf file.

However, KeaMA is not included in the Kea packages; instead, you find it in the sources of the legacy dhcpd. After compiling, you can use keama to convert your configuration. The command-line tool supports a number of options for this, the most important of which are summarized in Table 1.

Table 1

Some KeaMA Options

Option	Meaning
`-4`	Converts a DHCPv4 configuration
`-6`	Converts a DHCPv6 configuration
`-i`	Source file
`-o`	Output file
`-l`	Path to hook libraries

In the test, the converter worked quite well, even with my slightly more complex configuration; it even managed to import a second file. Parameters in the source file that KeaMA does not understand or that do not make sense to Kea (e.g., the object management application programming interface (OMAPI) configuration) are commented out in the target file. You will definitely want to check the results in depth.

« Previous 1 2 3 4 Next »