Delegate a domain
Per owned domain — create the zone in the panel, add records and the wildcard, then change the registrar's nameservers to ns1/ns2.spipdns.com and verify it propagated. Layer 1 made concrete.
With your nameservers set up, putting a domain onto them is the
Layer 1 action made concrete: you create the zone (Layer 2) in the panel, then change the
domain's nameservers at its registrar (Layer 1) to point at your ns1/ns2. Do this once per domain you
want to self-host.
Order matters: records first, then delegate — never the other way round
The one 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 goes dark — because you moved
authority to boxes that never had the cp record. Copy the registrar's existing records into your
zone first (apex A/AAAA, www, mail MX/SPF/TXT, ftp, and anything else it already serves), so
the instant authority moves to your boxes they already have every answer. The DNS Servers page keeps this
order in front of you as an always-visible callout above the tabs. The full sequence:
- Enroll
ns1+ns2until both are healthy (the Nameserver boxes tab). - Create the zone so it goes active (the Self-hosted zones tab).
- Add every record —
cp,ns1,ns2, and everything the registrar already serves (copy them from the registrar first; Paste many does this in bulk). - Verify:
dig @<box-ip> name.example.com +norecreturns your answer. - DNSSEC at the registrar? Turn it off there first and wait for it to clear (see DNSSEC).
- Only now set glue + point the domain's nameservers at
ns1/ns2.
1. Create the zone in the panel
In Networking → Nameservers → Self-hosted zones → Create zone, enter the domain (e.g. example.com).
SpipCP creates the zone and pushes it to each nameserver box separately — so both ns1 and ns2 are
authoritative for it right away (one box being down doesn't block the create; it catches up when it returns).
The Self-hosted zones tab works one domain at a time (the Cloudflare model): a zone selector — a left rail on wide screens, a dropdown on narrow ones — lists your zones, and only the selected zone's records show. Your selection persists across visits, so you land back on the domain you were editing.
2. Add records (and the wildcard)
Pick the domain in the zone selector and its records show — that's where you manage what the domain answers. These are Layer 2, living inside your now-authoritative boxes:
| Record | Typical use |
|---|---|
| A / AAAA | example.com and subdomains → your node's IP(s). |
| CNAME | An alias (e.g. www → example.com). |
| MX + TXT | Mail routing and SPF / DKIM / DMARC, if you run mail. |
| SRV / CAA | Service discovery; restrict which CAs may issue certs. |
| Wildcard | *.example.com → catch every subdomain at once (use * as the name). |
Add record opens a dialog: a name (relative to the zone — www, @ for the apex, * for a
wildcard), a type, one or more values (one per line for round-robin A or multiple MX), and a
TTL (300s is a safe default). Editing a record changes its values and TTL; the name and type are
fixed.
To bring a whole zone across at once, use Paste many — the bulk-import dialog. It's built for exactly the go-live case: "Great for copying a zone out of Cloudflare/OVH before you delegate." Paste your old provider's export, review, and every record lands in the zone in one go — so your boxes hold the full set of answers before you point the domain at them.
Records live in the zone, not at the registrar
This is the part people miss. Once the domain is delegated to your boxes (step 3), the registrar holds no records — your nameservers do. Every A/MX/TXT lives here, in the zone, and that's the only place to edit them.
The apex SOA and NS records are managed for you (they define delegation itself) and can't be hand-edited here — that's deliberate, so the editor can't silently break who's authoritative. Every change is written to each box, and you see the result per box; if a box rejected the write you see it, never a fake success. What you see in the panel is what the boxes will answer.
Verify from a clean vantage — your own network can lie about port 53
Before you delegate, confirm your nameservers answer authoritatively from the outside — but do not
trust dig @<box-ip> run from your laptop or office. Many ISPs and networks transparently intercept
outbound port 53 and answer from their resolver, so your query never reaches your box. You'll see
recursive answers — the ra flag instead of aa, arbitrary domains resolving, counting-down TTLs —
that look exactly like "my box is misconfigured / it's an open resolver" when the box is actually fine.
The tell: query a known-good authoritative server (e.g. a big provider's own nameserver) from the
same network. If that also comes back recursive (ra), your network is the interceptor, not your
box. Verify the right way instead:
- From the box itself — use the panel's Terminal (a shell over the agent, no SSH needed):
dig @127.0.0.1 example.eu SOA +norecshould showflags: qr aaplus a SOA line.dig @127.0.0.1 example.com +norecshould returnstatus: REFUSED— proving it's authoritative, not an open resolver.- (
digmay need installing first:apt-get install -y dnsutils.)
- From a neutral external checker — Zonemaster in its "undelegated"
mode: enter your domain plus your nameservers-and-IPs
(
ns1.spipdns.com/203.0.113.1,ns2.spipdns.com/198.51.100.1). It queries from its own infrastructure and confirms authoritative + globally-reachable + not-a-recursor before you touch delegation. This is the correct pre-delegation gate.
Where to find Zonemaster's undelegated mode
Open zonemaster.net → Show options → tick Undelegated test, then add
each nameserver as name/IP (e.g. ns1.spipdns.com/203.0.113.1). Run it, and every module should be
green except a Delegation note that the parent still lists your old nameservers — that clears once you
do the delegation change below and it propagates.
3. Point the registrar at your nameservers
Now the Layer-1 move. At the registrar of example.com (the domain you're delegating — not the
nameserver domain), replace its nameservers with yours:
ns1.spipdns.com
ns2.spipdns.comThis moves the whole zone's authority from wherever it was (e.g. the registrar's default DNS, or a managed provider) to your boxes. It is not a record edit — it's the "who is authoritative?" answer changing. Remove any old nameservers so only your two remain.
Leave the optional 'associated IP' field blank
Some registrars' "use my own nameservers" form has an optional "associated IP" / glue field next to
each nameserver name. If your nameservers live under a different domain — the recommended pattern
(ns1/ns2.spipdns.com, see setup) — leave that field blank: the glue
already lives at the nameserver domain, so this delegation needs only the names. Only fill an IP if the
registrar genuinely requires in-domain glue (nameservers inside the very domain you're delegating). And
don't accept a pre-filled placeholder IP — clear it.
4. Verify it propagated
Back in the panel, use Verify delegation on the zone. SpipCP checks from outside that the domain's
parent now points to ns1/ns2.spipdns.com and that your boxes answer authoritatively for it.
Delegation propagation can take hours
Nameserver changes go through the registry and are cached by resolvers worldwide; full propagation can take anywhere from minutes to a day (bounded by the parent zone's TTL). The zone shows pending until Verify delegation goes green — that's normal. Don't pull the old nameservers' records elsewhere until delegation is confirmed, so resolvers mid-switch still get answers.
Right after you delegate, an external checker may still show the old nameservers, and Zonemaster may flag "parent ≠ child" — until the registry publishes the change and resolver caches expire. That's normal propagation, not an error; re-check after the parent TTL passes.
Once delegation verifies, the domain is fully on your nameservers — every future record edit in the panel takes effect on your own infrastructure. If you also want the zone signed, continue to DNSSEC.
Next steps
- DNSSEC — sign this zone and register its DS at the registrar.
- Failover — how the two nameservers keep the domain resolving.
- Domains & SSL — attach this domain to a site for HTTPS.
Set up your nameservers
Step by step — buy a nameserver domain, enroll two cheap VPS in different locations as nameserver nodes, let SpipCP install PowerDNS, then run the one-time glue wizard at your registrar and verify it.
Failover
Why two nameservers give you automatic failover with nothing to configure — resolvers try each NS in turn. What the panel's NS-health probe watches, and what to do when a box goes unreachable.