Will spatiumddi work here?

[tedbuchanan]

Current environment: IPAM: spreadsheet, DHCP: Linux ISC DHCPd serves everything, multiple locations, multiple vlans. DNS: Linux running BIND9 is serving split Internal/External resolving with Cloudflare secondary and AD servers delegated to serving AD members in their own domain. Interested in this project to bring all under one pane of glass. Wondering if the DNS portion will work for us.

[mzac]

Thanks for posting — your environment is almost exactly the profile SpatiumDDI is built for. Walking through each piece:

Split-horizon (internal/external views): BIND view statements are well-supported. Internal and external views can be defined per zone, with their own record sets, ACLs, and transfer configs. Your existing split-resolving model translates directly.

Cloudflare as secondary: this works at the protocol level — Cloudflare uses standard AXFR/IXFR with TSIG. SpatiumDDI manages the primary side (BIND), and you'd configure also-notify and allow-transfer pointing at Cloudflare's secondary nameservers, with a TSIG key for the transfer. Cloudflare itself stays configured on their side; you're just authoring the primary side correctly.

AD subdomain delegation: standard NS-record delegation from your main zone to your AD domain controllers. SpatiumDDI manages NS records pointing to external nameservers like any other resource record, so the delegation pattern translates. The AD side stays untouched — it just keeps serving its own subdomain. If you wanted to also manage the AD-served DNS from SpatiumDDI (rather than just delegating to it), there's an agentless path via RFC 2136 + WinRM, but that's optional — pure delegation works without touching AD at all.

One thing worth flagging since you didn't ask but it's the bigger migration: ISC deprecated DHCPd in 2022 in favor of Kea, which is what SpatiumDDI uses. ISC publishes a dhcp4-conf-to-kea migration tool that converts most existing DHCPd configs, so moving from your current DHCPd is a real path rather than a rewrite. Multi-location / multi-VLAN deployments are exactly Kea's strong suit — HA pairs, shared networks, subnet selectors, all native concepts.

The honest alpha caveat: not everything above is equally polished today, and DHCP for production should wait until the project is past alpha. The lowest-risk first step is IPAM-only deployment — SpatiumDDI as your source of truth replacing the spreadsheet, with your existing BIND and DHCPd continuing to serve live traffic. That alone is a meaningful upgrade, and it lets you evaluate the model without any operational exposure. Letting it manage zones and DHCP scopes is a separate decision you can make later or never.

Happy to dig into any of these in more detail.