1.1 DDI in one control plane

Part 1 · FoundationsOperator⏱ ~20 min✓ Knowledge check

Most networks keep their addresses in a spreadsheet, DHCP in one console and DNS in another, and sooner or later the three disagree. SpatiumDDI runs all three from one record.

This module gives you the mental model the rest of the course builds on: what the control plane decides, what the DNS and DHCP servers do, how a change travels between them, and how Ridgeline College, the network you’ll build, fits the model. There’s no lab here; module 1.2 puts your hands on the product.

What you’ll learn

• Explain what IPAM, DNS and DHCP each do, and why one source of truth stops them drifting apart
• Tell SpatiumDDI’s control plane from its data plane, and predict what keeps working when the control plane is down
• Trace how one change in SpatiumDDI reaches BIND9 and Kea
• Describe how IPAM, DNS and DHCP objects contain each other, and how settings inherit down the IPAM tree
• Apply the recommended setup order to Ridgeline College

Three services, one record

Service	Its job	At Ridgeline
IPAM (IP address management)	The authoritative ledger: what address space exists, how it’s divided, and which address belongs to what	10.20.0.0/16, carved into one /24 per VLAN
DHCP	Hands a device an unused address from a defined range, plus the settings it needs (router, DNS servers, domain), for a limited time	Staff laptops on VLAN 21 lease from 10.20.21.100–10.20.21.199
DNS	Turns names into addresses (print-01.corp.example.edu → 10.20.21.10) and, through reverse zones, addresses back into names	The zone corp.example.edu

When the three live in separate tools, they drift. The spreadsheet says 10.20.21.50 is free, DHCP has already leased it, and DNS still points an old name at it. DDI is the industry’s name for running DNS, DHCP and IPAM as one system so that they can’t drift apart. In SpatiumDDI, allocating an address in IPAM is what creates its DNS records, and DHCP ranges are defined on the same subnets IPAM tracks.

The control plane and the data plane

SpatiumDDI splits the work in two.

One control plane decides; the data-plane servers serve · Adapted from the SpatiumDDI documentation (Apache-2.0)

• The control plane decides. It’s the web UI, the REST API, background workers and their scheduler, PostgreSQL and Redis. PostgreSQL holds the desired state of every space, zone, scope and address. Every action in the UI is a REST call, so your scripts can do anything the UI does (module 2.3).
• The data plane serves. DNS and DHCP servers answer the queries and hand out the leases. SpatiumDDI itself never answers a DNS query or a DHCP request.

The data plane comes in two shapes, and one installation can mix them:

• Agent-managed servers. SpatiumDDI ships BIND9, PowerDNS, Technitium and Kea as container images with a SpatiumDDI agent inside. The control plane decides their configuration, and the agent applies it to the daemon next to it. Your lab runs two of them: dns-bind9 and dhcp-kea.
• Agentless servers. Existing Windows DNS and DHCP servers and cloud DNS providers stay where they are. The control plane drives them remotely over their own protocols, such as RFC 2136, WinRM or the provider’s API, with nothing installed on them.

When the control plane is down

Every agent keeps its last-known-good configuration on local disk and serves from it, so a control-plane outage freezes changes, not service.

Keeps working	Waits for the control plane
DNS answers from every agent-managed server	The web UI and the API
DHCP leases from Kea	Every change: records, zones, scopes, reservations
An agent that restarts, which comes up from its cached configuration	Scheduled jobs, and new data reaching the dashboards

How a change reaches the servers

Follow one change at Ridgeline. In module 1.7 you’ll allocate 10.20.21.10 to print-01 in the staff subnet:

1. The API checks your permissions, then writes the address, an A record in corp.example.edu, a PTR record in the reverse zone and an audit-log row, all in one database transaction.
2. It queues one update for each DNS server in the zone’s server group, and wakes their agents.
3. The dns-bind9 agent applies the update to BIND9 as an RFC 2136 dynamic update: no zone-file editing, no reload. It confirms on its next heartbeat.
4. Seconds later, dig @127.0.0.1 -p 1053 print-01.corp.example.edu answers 10.20.21.10.

DHCP changes travel as configuration. When you create a scope or a pool, the control plane rebuilds the DHCP server group’s configuration. The dhcp-kea agent, which keeps a request open to the API waiting for changes, receives it within seconds, renders Kea’s configuration, has Kea test it, and applies it. You never edit a Kea file or push anything by hand.

Leases flow the other way: Kea reports them, so IPAM can show which addresses are in use. The lab has no real DHCP clients, so you won’t see leases there.

Three containment models

Every object in SpatiumDDI lives inside another. Learn the three trees and most screens explain themselves.

IPAM: space, block, subnet, address

IPAM containment · Adapted from the SpatiumDDI documentation (Apache-2.0)

Level	What it is	Ridgeline
IP space	A separate address domain, like a VRF. Subnets can overlap between spaces, never inside one	Campus
Block	An aggregate that gives the tree its shape and holds settings for everything below it. Blocks can nest	10.20.0.0/16 “Ridgeline campus”
Subnet	A real network, usually one VLAN. It’s the only level that holds addresses	10.20.21.0/24 “Staff VLAN 21”
Address	One IP, assigned to one device	print-01 = 10.20.21.10

DNS: server group, servers and zones, records

DNS is group-centric · Adapted from the SpatiumDDI documentation (Apache-2.0)

• A DNS server group holds the configuration: zones, split-horizon views, access lists, blocking lists, TSIG keys and shared options. Servers are its members, and every member serves the group’s zones.
• A group runs a single DNS engine. Ridgeline’s runs BIND9.
• A zone holds records. Forward zones map names to addresses; reverse zones map addresses back to names.
• At Ridgeline: the group default, the server dns-bind9, and the zone corp.example.edu.

DHCP: server group, servers and scopes, pools and reservations

DHCP is group-centric too · Adapted from the SpatiumDDI documentation (Apache-2.0)

• A DHCP server group holds scopes, client classes and settings, and every member server renders the same configuration.
• A scope binds one IPAM subnet to the group, so the group’s servers serve that subnet. A subnet has at most one scope per group.
• Inside a scope, pools decide what’s offered: dynamic ranges are handed to clients, excluded ranges are never offered, and reserved ranges are held for static use. A reservation, or static assignment, ties one MAC address to one IP.
• Leases belong to each server, because each Kea keeps its own lease file.
• At Ridgeline: the group default, the server dhcp-kea, and the scope “Staff VLAN 21” on 10.20.21.0/24.

Why zones and scopes belong to groups, not servers

SpatiumDDI fans every change out to each server in a group. In a DNS group, every agent-managed server runs its own authoritative copy of every zone, and each record change is queued once per server; there are no zone transfers between them to set up. So adding an agent-managed server to a DNS group gives you another full copy of everything the group serves, with nothing to copy by hand.

In a DHCP group, every member renders the same Kea configuration, and two Kea members can run as a high-availability pair (module 3.4).

Settings inherit down the IPAM tree

You don’t configure DNS and DHCP on every subnet. A DNS server group, a primary zone and a DHCP server group set on a space or a block apply to every subnet below it, unless the subnet overrides them.

• An unset value means “inherit”: SpatiumDDI walks up the tree to the first level that sets one.
• DNS and DHCP inherit independently. A subnet can inherit its DNS settings and still pin its own DHCP group.
• In the block and subnet dialogs, the DNS and DHCP tabs each have an Inherit from parent checkbox.

Ridgeline uses this once. In module 1.5 you’ll pin the default DNS group, the zone corp.example.edu and the default DHCP group on the block 10.20.0.0/16, and leave the subnet on inherit. Staff VLAN 21 then needs no DNS or DHCP settings of its own, and neither will any 10.20.<VLAN>.0/24 subnet you add later. Inheritance reaches reverse DNS too: when you save the subnet, SpatiumDDI creates its reverse zone, 21.20.10.in-addr.arpa, in the DNS group the subnet inherits.

Platform settings (module 1.2) are something different: they pre-fill the forms you create objects with.

Ridgeline College: the network you’ll build

Ridgeline College is a fictional one-campus college, the worked example in SpatiumDDI’s own Getting Started guide. Its internal domain is corp.example.edu and its campus network is 10.20.0.0/16, with one /24 per VLAN numbered after it: VLAN 21 is 10.20.21.0/24. It runs the built-in BIND9 and Kea servers, which are already running in your lab.

SpatiumDDI’s recommended setup order follows the trees from the servers down: servers → zones and scopes → subnets → addresses. Addresses are the leaves, and everything above them has to exist before SpatiumDDI can publish a record or a reservation anywhere. The course follows the same order:

Module	What you build at Ridgeline
Lab 0	The lab, with dns-bind9 and dhcp-kea registered in their default groups
1.2	A secured admin account, an environment banner, and reviewed platform settings
1.4	The forward zone corp.example.edu
1.5	The space Campus, the block 10.20.0.0/16, and the subnet 10.20.21.0/24 with its reverse zone 21.20.10.in-addr.arpa, which SpatiumDDI creates for you
1.6	The DHCP scope for Staff VLAN 21, with a dynamic pool and an excluded pool
1.7	print-01 with its A and PTR records, and a DHCP reservation for the camera cam-01
1.8	Ten lab PCs in one bulk allocation, plus everyday search and tools
Part 2	A helpdesk group, sign-in security with two-factor for Jordan, an API token, a restore from Trash, query logging and an alert rule, and backups

Knowledge check

Knowledge check · 6 questions

DDI in one control plane

1. Ridgeline's SpatiumDDI control plane (API, database and UI) is down for an hour of maintenance. What happens to DNS answers and DHCP leases on campus?

They stop until the control plane is back, because the API answers every queryDNS keeps working but DHCP stops, because leases are written to PostgreSQL firstBIND9 and Kea keep serving from cached config; only changes wait for the control planeThe agents fall back to an empty default configuration until the control plane is reachable again

SpatiumDDI is the control plane: it decides what the configuration should be. BIND9 and Kea are the data plane and do the answering. Every agent caches its last-known-good config on local disk and keeps serving while the control plane is unreachable, so an outage freezes changes, not service.

2. Which list shows the IPAM hierarchy from the top down?

Space → Block → Subnet → AddressBlock → Space → Subnet → AddressSubnet → Space → Block → AddressZone → Space → Subnet → Address

A space is the whole addressing universe (Ridgeline's Campus), a block is an aggregate such as 10.20.0.0/16, a subnet is an operating network such as 10.20.21.0/24, and an address is one IP. Scopes and DNS records hang off this tree.

3. Before SpatiumDDI, Ridgeline kept addresses in a spreadsheet and edited DHCP and DNS in their own consoles. Which problem does one source of truth solve?

It removes the need to run separate DNS and DHCP servers, because SpatiumDDI answers queries itselfEach team can keep its own copy of the data and merge the copies nightlyEvery client gets a static address instead of a lease, so records can't go staleIPAM, DNS and DHCP stop drifting apart, because allocating an address in IPAM creates its DNS records

When the address ledger (IPAM), the front desk (DHCP) and the directory (DNS) are maintained separately, they drift: the spreadsheet says an address is free while DHCP has leased it. In SpatiumDDI, allocating an address creates its DNS records, and DHCP ranges are defined on the same subnets. PostgreSQL holds the desired state, and the DNS and DHCP servers are projections of it.

4. Where do DNS zones and DHCP scopes live in SpatiumDDI?

On individual servers, so that each server keeps its own separate set of zones and scopes to serveOn server groups, which hold the member servers plus the zones or scopes they all serveInside IP spaces, next to the blocks and subnets they coverIn Settings, as platform-wide defaults that every server applies

DNS and DHCP are group-centric. A DNS server group holds servers, views and zones. A DHCP server group holds servers, scopes and client classes, and every member renders the same configuration. That's why you create groups and get servers into them before you create zones and scopes.

5. You're building Ridgeline on a fresh install. Which sequence follows the recommended setup order?

Settings → IP space → block → subnet → addresses → DNS server group and servers → zones → DHCP group and servers → scopesSettings → DNS groups and servers → zones → DHCP groups and servers → space → block → subnet → scopes → addressesAddresses → subnets → blocks → IP space → DNS zones → DNS server group → DHCP scopeDHCP scope → subnet → block → IP space → zones → DNS server group → Settings

Addresses are the leaf. Everything above them has to exist before SpatiumDDI can push a record or a reservation anywhere useful: servers → zones/scopes → subnets → addresses. Auth providers are optional and fit after Settings, or later.

6. Select all the jobs that belong to the data plane in the Ridgeline deployment.

Select all that apply.

Handing out leases from 10.20.21.100–10.20.21.199 (Kea)Storing the desired configuration in PostgreSQLServing the web UI and the REST APIAnswering DNS queries for corp.example.edu (BIND9)

The data plane does the serving: BIND9 answers queries and Kea hands out leases. The API, UI, workers and database make up the control plane, which decides what the configuration should be but never answers a DNS query or a DHCP request itself.

Check answers

Go deeper

• Getting Started: setup order: the official walk-through of Ridgeline College, with a glossary of DDI terms
• System architecture: the control plane, the data plane, and how configuration reaches the agents
• Data model: the IPAM, DNS and DHCP hierarchies in detail
• IPAM feature specification: spaces, blocks, subnets and addresses
• DHCP feature specification: server groups, scopes, pools and reservations

Finished 1.1 DDI in one control plane?

Mark it complete to track your progress (stored only in this browser).

Mark complete