SpipCP
DNS

DNS in SpipCP: the two layers

Learn the one model that prevents most DNS confusion — delegation (the nameservers, set at your registrar) versus the records (A/CNAME/TXT, inside whoever is authoritative) — then pick a posture.

Everything network-facing lives in one place: the Networking section. It gathers how your domains resolve (DNS), the certificates that secure them (SSL/TLS), and your own nameserver boxes — a single home, a bit like Cloudflare, except you choose the posture and nothing of yours is proxied or terminated upstream unless you ask for it.

Networking ▸  Domains · Providers · Nameservers · Edge proxy · SSL
  • Domains — the fleet-wide inventory: one row per hostname, each tagged with its detected authority tier (Hosted / Connected / External). Before you attach anything, this page is the posture chooser + the demarcation matrix.
  • Providersmanaged provider accounts (the cascade), each showing the zones it holds, plus the switchboard for which providers you offer.
  • Nameservers — your own PowerDNS boxes and the self-hosted zone + record editor; each row links across to its Node, and a nameserver node links back here.
  • Edge proxy — front an IPv6-only origin with your own public-IPv4 edge boxes.
  • SSL — the certificate authorities (issuers) you trust, bring-your-own certificate upload, and the fleet cert-scenario coverage. (Per-domain cert state lives on Domains.)

Who controls your DNS? The three tiers

Every hostname is one of three detected tiers — Hosted (your nameservers), Connected (a provider account you hold), or External (someone else's DNS). The tier is detected, never picked. See Domains: the three tiers.

Before you pick, learn the one model that makes the choices make sense. It prevents most DNS confusion.

The two layers

Every domain's DNS is really two separate things stacked on top of each other. Mixing them up is the top cause of "I changed a record and nothing happened."

Layer 1 — delegation: who is authoritative

Set at your registrar, on the domain. It answers "who is authoritative for example.com?" — the nameservers. Today that's probably something like *.ns.cloudflare.com; with self-hosted DNS it becomes ns1.spipdns.com / ns2.spipdns.com. Changing the nameservers moves the whole zone's authority to a different system. It's not a record swap — it's "move house."

Layer 2 — the records: what the answers are

A / AAAA / CNAME / MX / TXT, and the wildcard. These live inside whoever is currently authoritative (the nameservers from Layer 1). With a managed provider, the panel writes them through that provider's API. Self-hosted, the panel writes them onto each of your own boxes. Editing a record never changes who's authoritative — it changes the answers that authority gives.

The rule that follows: a record only takes effect inside the nameservers your domain is currently delegated to. If example.com is delegated to Cloudflare but you add the record at Bunny, nothing happens — Bunny isn't authoritative for that domain. Get Layer 1 right first, then Layer 2.

Where each path sits

Layer 1 (delegation)Layer 2 (records)
Managed providerAlready done by you — you delegated to the provider's nameservers when you set the domain up there. SpipCP doesn't touch it.SpipCP writes them via the provider's API (the DNS account cascade).
Self-hostedSpipCP owns this too — you delegate to your ns1/ns2.spipdns.com, which is why it needs the glue wizard and the nameserver boxes.SpipCP writes them onto each of your own boxes.

A managed provider only touches Layer 2 — you already handled delegation when you pointed the domain at that provider. Self-hosted owns both layers, the extra responsibility (and ownership) of running your own nameservers.

Choosing a posture

Every branded subdomain (roadmap.app1.com, *.roadmap.mydomain.com) needs DNS to resolve and a TLS certificate to serve. Before you attach anything, the Domains page presents three postures side by side so you pick one knowingly; once you attach your first hostname it becomes the fleet inventory. (The TLS half is always Caddy on your own node — see the passthrough guarantee.)

In one line:

  • Managed provider: least work, but a third party — possibly US-hosted — holds your records. EU options (Bunny, Hetzner, deSEC, Gcore) keep it managed but off US soil.
  • Self-hosted: you own both layers end to end — true data ownership — at the cost of running two nameserver boxes yourself.
  • Manual (BYO DNS): keep DNS wherever it is today and add the attach record by hand.

The demarcation matrix

The Domains empty state renders this as a live capability matrix per posture — what each one automates. The values are read from each provider's capability contract, never hard-coded:

Managed providerSelf-hosted nameserversManual (BYO DNS)
Self-service records✅ panel writes them via the provider API✅ full editor in the panel❌ you add them by hand
Wildcard cert (*.x)✅ DNS-01 automatic✅ DNS-01 automatic❌ no credential to write the TXT
Per-host cert✅ HTTP-01 or DNS-01✅ HTTP-01 or DNS-01✅ HTTP-01 only
Hands-off onboarding✅ fully scriptable✅ fully scriptable❌ a manual record step
Data ownershipprovider holds your recordsyou hold everythingwherever your DNS lives

Self-hosted is now wildcard-capable too

Self-hosted nameservers used to be limited to per-host (HTTP-01) certificates. They now self-solve the DNS-01 challenge against your own PowerDNS box, so the self-hosted posture earns the same ✅ for wildcards (and full scriptability) as a managed provider — with none of the third-party trust. Both fully-automated columns can drive scripted onboarding end to end.

Where to go next

On this page