By Yair Knijn · June 25, 2025

DNS said one thing, the IP plan said another, and the migration trusted the wrong one

The NetOps lead signs off on the cutover because the diagram agrees with itself. DNS resolves the name, the DHCP scope lists the address, the IPAM record names the host, and all three say the same thing. So the migration trusts the name, repoints a load balancer, and moves on. The assumption underneath is the dangerous part: that these three systems are one source of truth wearing three hats. They are not. They are three independent ledgers, each maintained by a different process on a different cadence, and they have been quietly disagreeing for months.

Drift does not announce itself. It shows up as a service that comes back up answering for a host that was decommissioned in March, and an on-call engineer staring at a green dashboard while traffic lands on the wrong box.

Three sources of truth, three independent drift rates

DNS changes when someone edits a zone or a dynamic update fires. DHCP changes when a lease is granted, renewed, or expires. IPAM changes when a human remembers to update the spreadsheet, which is to say rarely and late. These are not synchronized clocks. A lease can expire and free an address in DHCP while the matching A record lingers in DNS and the IPAM row still reads "assigned, prod, do not touch." Nothing in the stack forces these three views to agree, so they drift at whatever rate their slowest human owner allows.

The migration trusts whichever one the runbook happened to reference. If the runbook says "follow the name," it trusts DNS. If it says "the address in IPAM," it trusts the spreadsheet. Neither is automatically right, and the gap between them is exactly where traffic goes when you guess.

Forward and reverse DNS records that outlive their hosts

This is the mechanism, and it is not exotic. Most DHCP clients, Windows included, do not release their address on shutdown, so they never send the dynamic update that would remove their forward record. The DHCP server does not clean up the PTR either. The host is gone; the records are not. Microsoft's own guidance points operators at DNS aging and scavenging to clear these out, and the same documentation will tell you scavenging is one of the most common reasons records vanish that should have stayed. You are choosing between stale records and missing ones, and most shops pick stale by default because they never turned scavenging on.

So a forward record points at an address that DHCP reassigned to a different machine weeks ago. The reverse PTR still names the dead host. Forward and reverse no longer describe the same thing, and anything doing forward-confirmed reverse DNS quietly fails or, worse, succeeds against the wrong identity.

How drift turns a clean cutover into a wrong-host outage

Here is the failure in order. The IPAM record reserves 10.30.12.40 for an app server retired last quarter. DHCP handed that same address to a print server six weeks later. DNS still resolves app-prod-04 to 10.30.12.40 because the record was never scavenged. The cutover trusts the name, points production traffic at app-prod-04, and the requests land on a print server that answers with resets and timeouts. The dashboard is green because every individual system is internally consistent. The outage lives in the disagreement between them, which no single console shows.

• The IPAM record was never reconciled against the live lease table after the retirement.
• The DNS record was never scavenged, so the stale name survived.
• DHCP reassigned the address on schedule, doing exactly its job.
• The cutover trusted one ledger and never cross-checked the other two.

Continuous DNS/DHCP/IPAM reconciliation as the cutover gate

A point-in-time audit the week before go-live is theater, because drift resumes the moment the audit ends. The gate has to be continuous reconciliation that runs the three views against each other and refuses the change when they disagree. For every address in scope, confirm the lease state in DHCP, the forward and reverse records in DNS, and the IPAM assignment all describe the same host, and flag the row when any one diverges. That is the difference between a green dashboard and a true one.

This is what Spot IPAM treats as the baseline, not an add-on. Each Environment continuously reconciles its IPAM records against the leases DHCP actually grants and the names DNS actually serves, surfaces stale forward and reverse records before a cutover trusts them, and holds the change until the three ledgers agree. You can see how the reconciliation gate works on the features page. The migration should never have to guess which source of truth was telling the truth.