IP Address Management and DNS Automation: What Happens When Two Sites Get the Same /24?

The outage that takes three days to diagnose

A regional provider brings up a new aggregation site. The engineer allocates 10.42.16.0/24 from the addressing spreadsheet, which shows it as free. It is not free. It was assigned to a management network at a site acquired in a 2019 deal, recorded in that company's own spreadsheet, and never merged into the master when the tabs were combined. The two networks do not touch today. They will touch in four months when the core is meshed, and the resulting fault will present as intermittent unreachability to management interfaces that no one associates with an allocation made a third of a year earlier.

This is the characteristic failure of spreadsheet addressing: the cost is not paid when the mistake is made, it is paid much later by someone who has no way to trace it back. Meanwhile the reverse problem runs in parallel. Address space sits allocated to projects that were cancelled, hosts that were decommissioned and customers who churned two years ago, and nobody reclaims it because nobody can prove it is genuinely unused. So the organisation is simultaneously double allocating and hoarding, and both conditions are invisible.

Address space is an asset with a price, and finance has noticed

The IANA free pool of IPv4 addresses ran out in 2011 and the regional registries followed, ARIN reaching exhaustion in 2015. Since then IPv4 blocks have been bought and sold through registry approved transfers, which means the space your organisation holds is a balance sheet item rather than an administrative detail. That changes the conversation internally. A network team that can demonstrate genuinely unused space that could be returned to the pool or transferred has a financial argument, and a team that cannot say what it uses is holding an asset it cannot value.

Registry obligations run alongside this. Your allocations to customers or internal organisations are supposed to be reflected in registry records, and increasingly you are expected to maintain route origin authorisations under RPKI so other networks can validate your announcements. When the internal record of who holds which block is a spreadsheet, the registry data drifts from reality, and the drift shows up as a routing security question you cannot answer confidently.

What Infoblox, BlueCat, NetBox and phpIPAM actually solve

The commercial DDI products, Infoblox, BlueCat and EfficientIP, are strong when what you need is integrated DNS, DHCP and address management on a reasonably conventional enterprise network. They run the services as well as recording them, which is genuinely valuable and is the main reason to buy one. SolarWinds IP Address Manager is a lighter option in the same space.

On the open source side, NetBox has become the default source of truth for a lot of networks and deserves its reputation. phpIPAM is a solid address tracker. Both give you a data model and an API, which is a much better starting point than a spreadsheet.

Where these stop for a service provider or a large acquired estate is reconciliation. Every one of them assumes a record that someone maintains. The hard problem in a network that grew through acquisition is that the record and the network disagree, and closing that gap requires discovery, normalisation and a conflict resolution process written against your specific device mix, your specific naming conventions and the specific historic quirks that four different network teams left behind. A product will happily import your spreadsheet, including its errors, and then be authoritative about the wrong thing.

The second gap is provisioning. In a provider network, address allocation is not an administrative task, it is a step inside service activation. When a customer circuit is ordered, addresses have to be allocated from the right pool for that service type and site, DNS records created, reverse zones updated, the assignment recorded against the customer, and all of it reversed cleanly on churn. Products expose APIs that let you build that, which means you are building it anyway, and the question becomes whether the product is helping or constraining the workflow you actually need.

Discovery and reconciliation is the real work

A build in this category starts by admitting the record is wrong and designing for it. Pull the actual state from the network: configured interfaces and their addresses from device configurations, ARP and neighbour tables to see what is live, routing tables to see what is announced, DHCP lease data, cloud provider address assignments, and the DNS zones themselves. Then compare that against the intended state in the record.

Every disagreement is one of a small number of cases, and naming them is what makes the project tractable. Space recorded as allocated with nothing live in it, which is reclaim candidate. Space live in the network with no record, which is shadow allocation and the most urgent. The same block recorded twice, which is the conflict that causes outages. DNS records resolving to addresses that are not assigned to anything, which is the stale record problem. Reverse zones that do not match forward records. Build a queue per case type with an owner, and work it down. This is unglamorous and it is where the value is: most networks discover a meaningful amount of reclaimable space in the first pass, and the reclaim frequently pays for the project.

Allocation has to be a request, not an edit

Once the record is trustworthy, protect it. Engineers should not edit the inventory, they should request from it. A request states the purpose, the site, the service type and the size needed, and the system allocates from the correct pool according to your addressing policy, records the requester and the purpose, creates the DNS entries, and sets a review date. Allocation with a review date is the mechanism that stops hoarding, because unreviewed space eventually surfaces in a reclaim queue rather than living forever.

Encode your addressing policy as data. Real networks have conventions with meaning: a site gets a /20, management is always the first /24 within it, point to point links come from a specific range, customer allocations by service tier come from separate supernets to keep aggregation clean. Those conventions are usually in an engineer's head or a design document from 2018. Writing them into the allocation engine is how they survive the engineer.

IPv6 needs deliberate treatment rather than being bolted on. The addressing logic is different because scarcity is not the constraint, structure is: you are allocating /48s and /64s in a hierarchy designed for aggregation and readability, not packing space efficiently. Systems designed only around IPv4 scarcity model this badly, and retrofitting is worse than planning for it.

DNS automation and the stale record problem

Stale DNS is not just untidy. A record pointing at an address that has since been reassigned is a routing of traffic to the wrong service, and a dangling record pointing at a released cloud address is a subdomain takeover risk that security teams take seriously.

Tie DNS to the lifecycle rather than treating it as a separate task. When an allocation is created, forward and reverse records are created with it. When it is released, they are removed, or flagged if something still resolves to them. Run continuous validation comparing zone contents against the assignment record and against what actually answers, and queue the mismatches. This is the piece that most estates never build and it is a couple of weeks of work once the inventory exists.

What it costs and how long it takes

From the projects Digital Heroes has delivered, a first release covering discovery from devices and DNS, reconciliation queues by conflict type, the allocation engine with your addressing policy encoded, and an API runs $60,000 to $130,000 and ships in 10 to 14 weeks. The full build adding DNS automation with lifecycle tied records, provisioning integration into service activation, registry and RPKI record synchronisation, IPv6 hierarchy management and reporting on utilisation and reclaim runs $150,000 to $350,000 phased over 6 to 12 months.

What drives cost up: the number of device vendors and generations discovery has to speak to, since collecting from a current platform and from a fifteen year old switch are different exercises. Multiple DNS platforms, which is normal after acquisitions. Registry integration, because each registry has its own interfaces and rules. Provisioning integration, which depends entirely on how tidy your activation system is. And the volume of historic mess, which is genuinely the biggest variable and the one nobody can size until discovery runs.

What keeps it down: run discovery first as a short, separately scoped engagement. It tells you how bad the reconciliation problem is before you commit to the full build, and it produces value on its own.

When to buy instead

A single site enterprise with a few dozen subnets and one network team does not need this. NetBox or phpIPAM plus one enforced process will hold, and the discipline matters more than the tool.

A conventional multi site enterprise with clean records and a need for integrated DNS and DHCP should evaluate Infoblox or BlueCat properly. Running the services and recording them in one place is real value that a custom build does not give you unless you also want to run DNS yourself, which you probably do not.

Build when the record and the network disagree and reconciling them is the actual project, when address allocation has to happen inside automated service activation, when registry and RPKI obligations need to stay synchronised with internal allocations, or when you have acquired networks whose conventions you have to absorb rather than replace. The tell is simple: if your last three addressing incidents were caused by the spreadsheet rather than by a configuration error, the record is your problem.

How to choose a developer

Ask how they will discover actual address usage across your device mix, and expect specifics: configuration parsing, neighbour and ARP tables, routing tables, DHCP leases, cloud APIs. A developer who plans to import your spreadsheet and call it a source of truth has missed the point of the engagement.

Ask how they will handle conflicts, and listen for a queue per conflict type with owners rather than an error log. Ask what happens when discovery disagrees with the record: the system must never silently overwrite either side, because both are sometimes right.

Ask how they model IPv6, and be sceptical of anyone who treats it as IPv4 with longer strings. Ask what they have integrated on the DNS side, naming the platforms, and whether they have handled reverse zone delegation, which is where most DNS automation quietly breaks.

Get code and infrastructure ownership in writing at kickoff. At Digital Heroes the client owns the code from the first commit. Your address inventory is the map of your network, and renting the map from a supplier you cannot replace is a poor trade.