HyperOS Systems All articles
Operational Resilience

The Address Book Is Infrastructure: Proving DHCP and IPAM Survive a Site Loss

HyperOS Systems
The Address Book Is Infrastructure: Proving DHCP and IPAM Survive a Site Loss

In many UK regulated estates, IP addressing is invisible until it is not. A branch scope fills on a Friday afternoon, a DHCP failover relationship silently diverges, or a lease database is restored from a snapshot that predates the last subnet change. The immediate symptoms are familiar: users cannot onboard, clinical or payment devices fail to acquire an address, and support teams fall back to static workarounds that outlive the incident. The resilience question is not whether DHCP servers are backed up. It is whether the address allocation service, including its IPAM records and scope design, can continue to operate when a site is lost.

Define the service before testing the servers

A defensible audit starts with the service boundary, not the server inventory. For each site and business service, record the scopes in use, the relay paths that reach them, the DHCP failover or split-scope design, the DNS update path and the IPAM system that claims to be the source of truth. Include out-of-band management networks, voice and building systems, and any address ranges delegated to third parties. The output should be a dependency map that shows which physical locations, WAN links and platform teams must be available for a client to receive a lease.

This map often reveals that the nominal backup DHCP server sits in the same building as the primary, or that the secondary depends on a domain controller and DNS service that are also site-local. Such findings are not failures of the technology. They are failures of assumption, and they belong in the resilience register before the next audit cycle.

Lease persistence is the evidence that matters

DHCP is stateful. A server that starts successfully but has lost its lease bindings can create duplicate address assignments, break DNS records and provoke intermittent connectivity that is difficult to diagnose. The audit should establish how lease data is persisted, how frequently it is captured, whether the capture is application-consistent and how quickly it can be returned to service.

For Windows DHCP, this means examining backup schedules, database and registry export routines, and the consistency of lease state across failover partners. For appliance or open-source platforms, it means validating the supported backup mechanism rather than relying on virtual machine snapshots alone. Test restoration into an isolated network and confirm that leases can be queried without exposing clients to stale bindings. The question to answer is precise: if the primary site is unavailable, can the surviving service issue leases that reflect the most recent known state, and what is the maximum acceptable loss of lease history?

Reconcile IPAM against the network in both directions

IPAM reconciliation is often performed in one direction only: comparing IPAM records to what the network observes. A stronger control compares both directions. Every active address should have an owner and a record; every record should correspond to an active or intentionally reserved address. Exceptions should be documented, time-bound and reviewed.

In practice, drift accumulates through manual reservations, abandoned project subnets, static assignments for devices that were later virtualised, and DNS records that no longer match DHCP leases. A quarterly reconciliation, with monthly spot checks on high-change scopes, gives UK estates a defensible evidence trail. The report should distinguish between tolerated exceptions and unresolved conflicts, and it should name the accountable owner for each.

Monitor scopes as capacity, not just as alerts

Scope utilisation monitoring frequently stops at a threshold alert. That is insufficient for resilience planning. The audit should examine forecast runway, peak occupancy, transient spikes from guest or bring-your-own-device traffic, and the behaviour of scopes that serve devices with long lease durations. It should also monitor relay agent health, discover and offer rates, negative acknowledgements and failover state transitions. These signals belong in the wider observability platform, not in a standalone console that nobody reviews outside an incident.

For organisations with branch offices and intermittent WAN links, scope monitoring should include the local survivability mode. If a branch loses its WAN connection, can it still allocate addresses, and for how long? The answer should be documented as a designed capability, with limits and test evidence, rather than discovered during an outage.

Restore testing must simulate site loss

A restore test that returns a DHCP database to the same server in the same subnet proves very little. The meaningful scenario is site loss. Declare the primary site unavailable, bring up the surviving service in an isolated or alternate environment, restore IPAM in read-only mode where appropriate, and validate that clients on representative VLANs can obtain leases, resolve names and reach dependent services. Measure two timings: time to first successful lease and time to full scope coverage across the affected estate.

The test record should include the configuration baseline used, the lease data recovery point, the failover state observed and the reconciliation performed afterwards. Any manual steps should be converted into runbooks or automation candidates. Where the test cannot be performed without disrupting production, a tabletop exercise with configuration evidence is better than an untested claim, but it should be labelled as such.

Control points for the 2026 audit cycle

UK regulated estates should assign clear ownership for DHCP and IPAM, incorporate scope and failover changes into change control, and protect the address management platform with the same privileged access discipline as other infrastructure. Firmware and platform support status should be reviewed alongside the resilience tests, particularly where DHCP appliances are approaching end of support. Board reporting should use a small set of measures: scopes above the agreed utilisation threshold, unresolved IPAM conflicts, failover pairs not in a healthy state, and the date and outcome of the last site-loss restore test.

Address allocation is not a peripheral service. It is the first dependency for most others. Treating DHCP and IPAM as infrastructure with an evidenced recovery path is a practical way for UK technology leaders to close a gap that rarely appears on the risk register until it is already causing operational harm.

All Articles

Related Articles

Provenance Before Power-On: An Inbound Regime for Refurbished Infrastructure

Expiry Dates for Integrations: A Deprecation Watchlist That Earns Board Attention

Expiry Dates for Integrations: A Deprecation Watchlist That Earns Board Attention

Registrar, Resolver, Record: Assembling a DNS Resilience Evidence Pack

Registrar, Resolver, Record: Assembling a DNS Resilience Evidence Pack