ISC DHCP’s OMAPI Bug Can Exhaust Server Memory

The October 1 notice says the result can degrade system performance or cause the operating system’s out-of-memory killer to terminate dhcpd. All ISC DHCP branches are already end-of-life. ISC recommends restricting OMAPI access to trusted hosts and moving to Kea.

I went through the ISC DHCP-to-Kea move at work a few months ago. It took an evening on a Salt-managed, three-node setup. The configuration kept assigning the same IP addresses, followed by a switchover. There was not much drama to it.

Start with the management listener

This advisory concerns access to OMAPI, not an ordinary DHCP request from a client looking for an address. That distinction is worth checking before deciding how exposed a particular server is.

ISC’s OMAPI configuration guidance says the interface is disabled by default, although sample configurations often enable it. Defining omapi-port in the configuration opens the listener. The documented example uses port 7911; inspect the configuration actually loaded by your service rather than assuming that is the port in use.

I would trace that setting through any included files, confirm the listening socket, and review the firewall rules on the host and along the management path. A server being inside the network does not tell me whether guest devices, user workstations, or an unrelated service can reach its control port.

If OMAPI is unused, ISC recommends leaving it disabled. If something depends on it, identify that caller before changing access. Shared keys protect control requests, but the new advisory describes an unauthenticated memory-exhaustion problem and recommends restricting connections. A configured key is not a reason to skip the reachability check.

The Kea move did not require rebuilding everything

The environment I migrated has three hosts, runs without Docker, and uses keepalived to control which single node provides the service. That is the deployment arrangement; I am not describing a three-way active Kea cluster.

Claude handled much of the migration work. I still needed to preserve the assignments and check the cutover; having generated configuration did not settle those questions.

Having the configuration managed in Salt gave the work a familiar place to live. The migration did not have to become a container project or an excuse to replace the rest of the stack. For this environment, changing the DHCP implementation was enough.

That experience is one reason I would investigate the scope before assuming an ISC DHCP replacement needs a large project. An evening is what this particular migration took, not an estimate for an unfamiliar network.

A reservation conversion you can compare

Here is an illustrative IPv4 example using documentation addresses, not the configuration from work. The ISC DHCP fragment pins one MAC address to an IP:

host lab-printer {
    hardware ethernet 02:00:00:00:00:42;
    fixed-address 192.0.2.42;
}

The corresponding Kea reservation belongs inside the matching subnet’s reservations array. This is a subnet fragment, not a complete server configuration:

{
  "id": 1,
  "subnet": "192.0.2.0/24",
  "pools": [
    { "pool": "192.0.2.100 - 192.0.2.199" }
  ],
  "reservations": [
    {
      "hw-address": "02:00:00:00:00:42",
      "ip-address": "192.0.2.42"
    }
  ]
}

The MAC and address are unchanged, and the reserved address sits outside this example’s dynamic pool. The lab-printer declaration label has not been turned into a hostname option. If clients require a hostname or other options, compare those separately. Kea’s reservation documentation explains the identifiers and placement rules; use the manual matching your installed version.

For a real conversion, replace the subnet, unique subnet ID, pool, and identifiers with the reviewed values for that network. Confirm which identifier the client sends rather than replacing client-ID or relay-based reservations with MAC matches indiscriminately. This example’s JSON and address relationships were checked offline; it has not been tested as a running DHCP service.

Write down what would make you reverse the cutover

I would use a short check sheet for each served network, with expected values filled in before the maintenance window:

Do this in an isolated test network first. Do not bring an uncoordinated second DHCP server onto the production network to see what happens. Preserve the previous configuration and determine how leases issued after cutover would be reconciled before treating a service restart as a rollback plan.

Check what needs to survive your cutover

Preserving configured IP assignments is not the same as transferring every active dynamic lease. If your environment depends on that lease state, include it explicitly in the plan. Keepalived choosing an active service does not, by itself, establish how DHCP leases are stored or synchronized.

ISC’s migration guide separates configuration conversion, testing, lease migration, and cutover. Its Kea Migration Assistant translates configuration but does not convert lease files. It also does not carry over reservations created through OMAPI or manually stored in the lease file. Those need separate attention.

The guide identifies option-inheritance differences and different failover mechanisms as other things to review. I would compare the behavior the clients need: address assignments, subnet selection, router and DNS options, relay handling, and anything used by network booting. A configuration that parses is only the first check.

For validation, I would test a fresh client request as well as a renewal, on the networks the replacement must serve. Check the returned options and address, and decide how you will reverse the cutover before doing it.

The immediate task is to establish whether the OMAPI listener is reachable from places it should not be. After that, inventory the configuration that needs to move. You may find that replacing the unsupported service is considerably less work than the untouched configuration made it look.