SpipCP Docs

Own your DNS end to end by running PowerDNS on cheap VPS as nameserver nodes. The trade-offs (two boxes, the upkeep, no anycast), how it works, and why it's worth it for data ownership.

Self-hosted DNS means you are authoritative for your domains — you run the nameservers, you hold the records, no third party sits in between. Where a managed provider only handles Layer 2 (the records, because you already delegated to it), self-hosted DNS owns both layers: you point your domains at your own ns1/ns2.spipdns.com, and SpipCP writes the records onto your boxes.

Why

Data ownership. Your records — who points where, your mail (MX/SPF/DKIM/DMARC), your subdomains — live on infrastructure you control, not a provider's account that could be suspended, priced up, or subpoenaed.
Off third-party (and US) soil entirely. Even the EU managed providers are still someone else's service. Self-hosting puts the whole stack under your own control.
No per-zone limits or lock-in. It's your DNS; add as many zones and records as the boxes hold.

The trade-offs

Running your own nameservers is real infrastructure. We won't pretend otherwise:

This is upkeep you take on, not a toggle

Two boxes are required, not optional. A single nameserver is a single point of failure for every domain you delegate to it. The whole point of ns1 + ns2 is that the second box is the backup — so they must be two separate VPS in different locations. Putting ns1 and ns2 on one box buys you nothing.
The upkeep is yours. Patching, uptime, and the registrar steps (glue + per-domain delegation) are work the panel guides but cannot do for you.
No anycast. Your two VPS sit in two locations; a big managed provider answers from dozens of points worldwide. For most sites two well-placed boxes are plenty, but if you need the lowest possible lookup latency or massive DDoS-absorbing DNS, a managed provider still wins. Choose self-hosted for ownership, not for anycast.

If the upkeep isn't worth it, an EU managed provider gets you off US-hosted DNS with none of this.

How it works

SpipCP runs PowerDNS on each nameserver box and writes to each box one at a time. The boxes share no database and no zone transfer between them; the panel pushes every zone and record change to each box on its own.

The panel drives each box's PowerDNS through the node's own agent — the same authenticated agent WebSocket that carries everything else — rather than reaching over a direct HTTP connection to the box. That keeps the PowerDNS API bound to localhost on each box and never exposed to the network: nothing listens publicly except port 53. It also means a box behind a strict firewall or NAT no longer shows as "unreachable" just because its API port can't be dialed from the outside — if the agent is connected, the panel can drive PowerDNS.

That buys two things:

One box down doesn't block edits. Because the panel writes to each box separately, a box being unreachable doesn't stop you editing DNS — the reachable box still takes the write, and the down one catches up when it returns.
Automatic failover. Both boxes are listed as nameservers for the domain, so resolvers try each one — if ns1 is unreachable, the world falls back to ns2 with nothing to configure. See Failover.

                  ┌─────────────────────────┐
                  │  You edit a record      │
                  │  in the panel           │
                  └────────────┬────────────┘
                               │  push to EACH box (via its agent →
                               │  localhost PowerDNS API)
                ┌──────────────┴──────────────┐
                ▼                              ▼
       ┌─────────────────┐            ┌─────────────────┐
       │  PowerDNS @ ns1 │            │  PowerDNS @ ns2 │
       │  location A     │            │  location B     │
       └────────┬────────┘            └────────┬────────┘
                ▲                              ▲
                └──────────────┬──────────────┘
                               │  resolvers try either,
                               │  fall back automatically
                  ┌────────────┴────────────┐
                  │  the world's DNS        │
                  │  resolvers              │
                  └─────────────────────────┘

  No shared DB · no AXFR — each box is written independently, so one box
  down never blocks a write, and failover is automatic.

A nameserver node is its own kind of node: SpipCP won't host instances or sites on it. It runs DNS and nothing else, and you add it through its own Add-a-nameserver flow under Networking → Nameservers (the Nameserver boxes tab) — not the generic add-node path. (The old DNS → DNS Servers link still works.) Each nameserver row links across to its underlying Node, and a role=nameserver node links back here. DNSSEC is supported (PowerDNS signs the zone and holds the keys; the panel reads the DS for you to enter at the registrar — see DNSSEC).

Wildcard certificates

Self-hosted nameservers are wildcard-cert-capable. A *.example.com certificate needs the ACME DNS-01 challenge — and because SpipCP owns the PowerDNS API on your boxes, the node's Caddy self-solves it via the compiled caddy-dns/powerdns module, writing and tearing down the _acme-challenge TXT for you. The result issues and auto-renews exactly like a per-host cert, so the self-hosted posture is fully automatable — no third-party DNS credential required. See SSL/TLS certificates for the full matrix.

How to get there

Everything lives under Networking → Nameservers in the panel — a page titled DNS Servers with two tabs, Nameserver boxes and Self-hosted zones. (The old DNS → DNS Servers link still works.)

Or follow the guided checklist

The Self-host nameservers journey on the Set up surface sequences this whole page's steps into one resumable checklist — box → box → glue → zone → records → DNSSEC-off → delegate → attach — and adds a Check now button to the two steps you do at your registrar: it resolves your glue records and your delegation from outside and tells you whether they're visible yet. The check is advisory, never a gate — a red result means "not yet propagated," not "you did it wrong."

Records first, then delegate — never the other way round

The single rule that governs go-live: records must exist on your boxes BEFORE delegation points at your boxes. Delegate first and, hours later, your own panel cp.example.com can be dark because you never added the cp record to your boxes. The DNS Servers page keeps this order in front of you as an always-visible callout above the tabs; the full six-step sequence is on Delegate a domain.

The DNS Servers page with the go-live order callout above the two tabs — The DNS Servers page — the always-visible go-live order callout above the tabs.

Setup — buy a nameserver domain, enroll two VPS as nameserver nodes, install PowerDNS, run the one-time glue wizard.
Delegate a domain — create the zone, add records, point the registrar at your nameservers, verify it propagated.
Failover — what two nameservers buy you and what the panel monitors.
DNSSEC — sign your zones and register the DS.

Run your own nameservers

Why

The trade-offs

How it works

Wildcard certificates

How to get there

On this page