3.2 Choosing DNS and DHCP engines

Part 3 · Architecture & operationsArchitect⏱ ~25 min✓ Knowledge check

SpatiumDDI authors zones and records the same way on every engine, so it’s tempting to treat the engine as a detail. It isn’t. Views, RPZ, ALIAS records, encrypted DNS and DNSSEC all behave differently per engine, and the engine is fixed per server group. Choose well and a new requirement later is one more record; choose badly and it means moving zones between groups.

What you’ll learn

• Compare the DNS engines on the features that decide real designs
• Apply the single-driver rule, and the one-signer rule for DNSSEC, when you plan server groups
• Pick a DHCP engine and know what Windows DHCP and FortiGate can and can’t do
• Plan a mixed estate and a BIND9-to-PowerDNS move without DNS downtime

The rule that shapes everything

You choose the engine (the driver) for each server when you add it, but a DNS server group is single-driver: the control plane rejects a group that mixes engines. Catalog zones, zone transfers and the engine-only features all assume that every member runs the same driver.

Engine-only features are enforced server-side. Ask for one on the wrong group and the API returns 422 with a remediation message such as “move the zone to a PowerDNS-only group”.

Feature	Allowed engines
ALIAS and LUA records	PowerDNS
SVCB, HTTPS and DNAME records	BIND9, PowerDNS, Technitium
DNSSEC sign	BIND9, PowerDNS, on a group with one agent server
DNSSEC unsign	BIND9, PowerDNS, Technitium
Manual key rollover	BIND9

A mixed estate is therefore one group per engine, and each zone lives in exactly one group. 1.0.0-beta.3 can move a server or a zone between groups: the zone move is a preview then commit, and the server move refuses to mix drivers or to add a second server to a group that holds DNSSEC-signed zones. At Ridgeline, the default group runs BIND9 through the auto-registered dns-bind9 agent.

Why a group runs one engine

A DNS server group isn’t a tag on servers; it’s where the configuration lives. Zones, views, ACLs and options belong to the group, and every member renders them into its own daemon as an independent authoritative copy. Catalog-zone semantics, zone-transfer shape and the feature gates all assume one driver per group. Enforcing that at the API means a group can’t quietly end up with a member that can’t express part of the group’s config.

DNS engines compared

Engines SpatiumDDI runs for you

These are agent-managed: the engine runs in a SpatiumDDI container with the agent baked in.

Capability	BIND9	PowerDNS	Technitium
How changes apply	TSIG-signed nsupdate over loopback; rndc for zones	REST rrset PATCH over loopback	REST over loopback
Views (split-horizon)	Yes, first-class	Tag-based, not in the UI	No
RPZ blocklists	Yes	No	Native blocking instead of RPZ
ALIAS / LUA records	No	Yes	No
DNSSEC	Inline signing from a dnssec-policy; BIND rotates keys; manual rollover	Online, one toggle	Not supported in 1.0; zones signed earlier keep serving, marked DNSSEC not managed
Catalog zones (RFC 9432)	Producer and consumer	Producer only	Not supported in 1.0
Encrypted DNS	DoT and DoH natively; forwards over DoT only	DoT/DoH only through an optional dnsdist front (Compose only for now); doesn’t forward	DoT, DoH and DoQ natively; forwards over all three
Dynamic-update ACLs	IP, TSIG, name scope and record type	IP and TSIG only	None
Queries on the Logs page	Yes	Yes	Not yet

Every agent engine signs with keys held on that server, and the control plane holds none of them. Two servers in one group would serve two different DNSKEY sets against one published DS, so SpatiumDDI allows signing only on a group with one agent server, and refuses a second server in a group that holds signed zones (#1762). To combine signing with redundancy, sign in a one-server group and serve copies from secondary zones in another group, the pattern under “Designing a mixed estate” below.

Engines that stay where they are

These are agentless: the control plane drives a server you (or a provider) already run. It applies each record change right after the database commit, and retries with backoff if the server refuses it.

Capability	technitium_api (experimental)	Windows DNS	Cloud DNS drivers
Who runs the server	You; it already exists	Your domain controllers	The provider
How changes apply	Technitium’s HTTP API	Path A: RFC 2136 on port 53, always. Path B adds WinRM for zone create/delete and record reads	The provider’s API
Zone create	Primary zones only	Path B only	Yes; no rename (delete and create)
DNSSEC	Stays in Technitium’s console	Manual, outside SpatiumDDI	Not managed (a provider-level toggle)
Dynamic-update ACLs	Not offered	Coarse: None, Secure or NonsecureAndSecure	None; the API returns 422
Views, RPZ, ALIAS/LUA	No	No	No

The cloud drivers cover Cloudflare, Route 53, Azure DNS and Google Cloud DNS, plus a token-only tier for DigitalOcean, Hetzner, Linode and Vultr.

Picking, in short

• BIND9 is the default and the reference implementation. It’s the only engine with views, RPZ and manual key rollover.
• PowerDNS when you need ALIAS (a CNAME-like record at the zone apex) or LUA computed records. ALIAS targets resolve through the group’s own forwarders over plain DNS, so set forwarders on the group: without them, new ALIAS records are refused (#1353).
• Technitium when you want to serve or forward encrypted DNS with no sidecar, DoQ included. In 1.0 it has no DNSSEC signing and no catalog zones (both are planned for 1.1.0), and its queries don’t reach the Logs page yet.
• technitium_api when a Technitium server already exists and should stay where it is. It’s experimental in 1.0: one server per group, Primary zones that SpatiumDDI creates, and their records; DNS pools, SOA and transfer settings, group options, catalog zones and blocklists are refused (#1784). It needs Technitium 15.0 or later and a permanent token from a dedicated user in Technitium’s built-in DNS Administrators group, not the admin account. Zones: Modify alone isn’t enough: it can’t delete zones, and it doesn’t see zones created before the user existed.
• Windows DNS when zones are AD-integrated and your Windows team keeps using DNS Manager. Path B needs a service account in DnsAdmins. SpatiumDDI doesn’t implement GSS-TSIG, so record writes to a zone set to Secure only fail.
• A cloud driver when the provider hosts the zones. Import them first, then manage them like any other group. Providers bill per hosted zone, so a cloud group creates no reverse zones at the provider unless you turn on Auto-create reverse zones at the provider in the group’s settings; until you do, subnets’ PTR records are skipped (#1932).

Tip

Every agentless engine comes with a connection test: Test Connection for Windows servers (and FortiGate on the DHCP side), and a credential probe for the cloud providers and technitium_api. Run it as soon as you add the server. It catches a wrong WinRM transport (the forms offer NTLM, CredSSP and Basic), an account missing from DnsAdmins, or a bad token before a sync fails on it.

From the field

An operator with spreadsheet IPAM, ISC dhcpd, BIND9 with split internal and external views, Cloudflare as a secondary and AD delegation asked whether SpatiumDDI would fit. The answer mapped each piece: BIND9 for the views, Cloudflare as a secondary over AXFR/IXFR with TSIG (also-notify plus allow-transfer), AD by NS delegation or the agentless Windows path, and the dhcpd configs moved to Kea. Do the same mapping for your own estate before you create a single group.

Source: GitHub discussion #125

Interactive · Which DNS engine?

Answer a few questions about the zones you need to serve. A DNS server group runs one engine, so if different zones need different engines, the answer is one group per engine.

DHCP engines

	Kea	Windows DHCP	FortiGate
Shape	Agent-managed container	Agentless, over WinRM	Agentless, over the FortiOS REST API
Writes	Full: the group’s scopes, pools, reservations and classes, checked with kea-dhcp4 -t in a separate process, then applied with config-reload	Read-mostly: lease and scope reads, plus per-object scope, reservation and exclusion writes; no config push	Full: the whole DHCP-server object for a scope, pushed before the database commits
HA	Kea’s own HA hook, configured on the group; DHCPv4 only	Windows failover relationships, read on each lease sync and managed from the group (needs CredSSP)	None
Leases into IPAM	The agent streams lease events	A scheduled pull (DHCP Lease Sync in Settings)	Read over REST
Credentials	Bootstrap key exchanged for an agent token	A service account in DHCP Users (read) or DHCP Administrators (writes and failover)	An API token and VDOM; TLS verification on by default

What to know before you pick:

• Kea is the full-featured choice. The agent drives it over Kea’s unix control socket. The image ships no HTTP control agent, so TCP 8000 is only the HA peer port, and the peers authenticate each other there with a per-group TLS client certificate once every member’s agent supports it.
• Windows DHCP suits estates that keep Windows. The lowest-risk pattern registers it read-only, so live leases mirror into IPAM while scopes stay managed in Windows. With two or more Windows servers in a group, SpatiumDDI reads their failover relationships and writes each scope only to the servers that hold it.
• FortiGate maps each scope to the interface whose primary IP and netmask match the scope’s CIDR. It records the object it created, and won’t overwrite a DHCP server it didn’t create unless you explicitly adopt it. If the REST push fails, the change is rolled back in SpatiumDDI too.
• Kea and Windows DHCP can’t share a group. The API refuses it with a 422, because Kea’s HA can’t coordinate with Windows failover, and a scope both served would be handed out twice (#1110).

From the field

Two Windows DHCP servers holding the same scope without a failover relationship are two independent servers handing out the same addresses, and neither reports a problem. On 2026.09.04-1 SpatiumDDI could cause exactly that: a scope written into a group of two Windows servers went to both, with the full pool.

Since 2026.10.02-1 it reads each server’s relationships and scopes on the lease-sync poll. Writes go only to the servers that hold a scope (both partners when a relationship covers it), a new scope goes to one server by its Windows placement, and the default-on DHCP scope served uncoordinated alert fires for any scope two servers serve without coordinating. The docs say this hasn’t been verified against a live failover pair yet, so test it on yours before you rely on it.

Source: GitHub issue #1110

Designing a mixed estate

PowerDNS primary, BIND9 at the edge

Driver crossover: one signing PowerDNS primary, BIND9 secondaries for redundancy · Adapted from the SpatiumDDI documentation (Apache-2.0)

Groups on different engines can serve the same namespace through plain zone transfers or RFC 9432 catalog zones. In this pattern a PowerDNS group takes the writes (online DNSSEC, ALIAS, LUA) and a BIND9 group serves the zones at the edge. Because PowerDNS signs, its group holds one server; the BIND9 secondaries carry the redundancy.

1. In the PowerDNS group (internal-pdns in the docs), turn on catalog zones and name the catalog, for example catalog.example.com..
2. In the BIND9 group (edge-bind), create each zone as a secondary whose masters list points at the PowerDNS primary, and turn on catalog zones with the same catalog name.
3. Changes then flow from the UI to PowerDNS, which bumps the serial; BIND9 picks them up by NOTIFY and IXFR.

A Technitium group can stand in for either side over plain AXFR, but not with catalog zones in 1.0. The simpler alternative is per-zone placement: zones that need ALIAS or LUA live on PowerDNS, zones that need views or RPZ on BIND9, and zones that need DoQ or encrypted forwarding on Technitium.

Moving a BIND9 group to PowerDNS without downtime

IPAM sync, RBAC and DDNS don’t change during this move, because they target zones by ID, not by engine.

1. Pre-flight. Find the zones that use views or RPZ. PowerDNS can’t take them, so leave them on BIND9. If you’ll sign on PowerDNS, plan that group with one server and put redundancy in a secondary group.
2. Stand up a PowerDNS group next to the BIND9 one and let its agent register.
3. Copy by AXFR. Create each zone in the PowerDNS group as a secondary of the BIND9 primary. Wait a sync cycle (about 60 seconds) and check that dig +short SOA returns the same serial from both. Don’t edit records during this window.
4. Promote. Move each zone to the PowerDNS group and switch it from secondary to primary. BIND9 can stay on as a read-only secondary for a soft cutover.

With the zones on a one-server PowerDNS group, you can then sign them there and publish the new DS records at your registrar. If something goes wrong before you promote, BIND9 is still authoritative: switch the zones back. After you promote, the BIND9 secondary still serves the last good copy, so move the zone back to the BIND9 group and set it to primary.

Caution

DNSSEC keys live on each agent’s own volume, whatever the engine (BIND9’s key files, PowerDNS’s LMDB, Technitium’s key store), not in the control-plane backup. If you lose that volume, the zone gets new keys and you have to publish new DS records at the registrar.

From the field

PowerDNS 5.0 upgrades its LMDB schema one way the first time it opens the database, and PowerDNS 4.9 can’t read it afterwards. The dns-powerdns image now snapshots the database before an upgrade, so rolling a node back takes two steps: redeploy the old image and run spatium-pdns-lmdb-guard restore latest.

Source: GitHub issue #638

Knowledge check

Knowledge check · 6 questions

Choosing DNS and DHCP engines

1. Ridgeline wants split-horizon views on corp.example.edu and ALIAS records on a separate web zone. How do you lay out the DNS server groups?

One group containing a BIND9 server and a PowerDNS serverTwo groups: a BIND9 group for the views zone and a PowerDNS group for the ALIAS zoneOne PowerDNS group, because PowerDNS supports views through tagsOne BIND9 group, entering the ALIAS records as CNAMEs at the apex

A DNS server group is single-driver. Views are BIND9-only and ALIAS is PowerDNS-only, so a mixed estate is one group per engine, with each zone in the group whose engine it needs.

2. What happens if you create an ALIAS record in a zone that belongs to a BIND9 group?

BIND9 renders it as a CNAMEThe API returns 422 with a remediation message pointing you to a PowerDNS groupThe record is saved but never servedThe agent quarantines the bundle that contains it

Engine-only features are gated server-side. Calling one against a group without a supporting driver returns 422 and tells you to move the zone to a group on a supporting driver.

3. Which engine is the only one that can forward upstream over DoH or DoQ?

BIND9PowerDNSTechnitiumWindows DNS

BIND 9.20 has no client-side HTTP or QUIC transport, so it forwards over DoT only, and PowerDNS doesn't forward at all. Technitium serves and forwards DoT, DoH and DoQ natively, with no sidecar.

4. A customer already runs a Technitium server and wants SpatiumDDI to manage its zones without deploying anything new. Which driver fits?

technitium, added to the same group as their BIND9 serverstechnitium_api, in a group of its ownwindows_dns Path A, because Technitium accepts RFC 2136None: import the zones once, then retire the server

technitium_api is agentless: the control plane drives the existing server's HTTP API with a permanent token from a user in Technitium's DNS Administrators group. It manages zones and records only; DNSSEC, forwarders and blocklists stay in Technitium's console. It's experimental in 1.0 and limited to one server per group, and groups are single-driver, so it needs a group of its own.

5. In 1.0.0-beta.3, what does SpatiumDDI do with a Windows DHCP server?

Pushes the full config bundle to it through the long-poll, like KeaReads leases, scopes and failover relationships over WinRM, with per-object writes and no bundle pushAdds it to Kea's HA hook when it shares a group with a Kea serverInstalls the SpatiumDDI agent on the Windows server

Windows DHCP is agentless and there's no bundle push. Scope, reservation and exclusion writes go per object over WinRM, and the lease-sync poll also reads each server's failover relationships, which you can manage from the group over CredSSP. A group can't mix Kea and Windows DHCP at all, so a Windows server never joins Kea's HA hook.

6. You're moving a BIND9 group to PowerDNS. Which zones should stay on BIND9?

Select all that apply.

Zones that use split-horizon viewsRPZ blocklist zonesZones signed with DNSSECZones with more than 1,000 records

The pre-flight looks for features PowerDNS can't take: classic views (PowerDNS uses tags, with no automatic translation) and RPZ (a recursor feature, not an authoritative one). DNSSEC is fine on a PowerDNS group with a single server, since PowerDNS signs online; SpatiumDDI refuses signing on a group with two agent servers.

Check answers

Go deeper

• DNS driver specification: per-engine capabilities, the one-signer rule, dynamic-update ACLs, encrypted transports and the technitium_api scope
• DHCP driver specification: Kea, Windows DHCP (including failover relationships) and FortiGate in detail
• DNS features: the driver-choice table and the feature gates
• Deployment topologies: the PowerDNS and BIND9 hybrid and the migration recipe
• Windows Server setup: WinRM, service accounts, zone settings and more than one Windows DHCP server in a group

Finished 3.2 Choosing engines?

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

Mark complete