DNS backends
A backend is where a zone's records are published. Every zone starts on the built-in one, this server's own name servers, and an account holder can move a zone to a hosted provider or to a DNS they update by hand. The publication pipeline is the same for all of them; the backend is the last step, behind a driver that knows that one server's API, spelling and limits.
The server has no setting for this. The default backend is the built-in, set by the panel's own package, and a zone that has expressed no preference uses it. Which backend serves a zone is the zone's own choice, stored on the zone and made by its owner on the zone's General tab (the Backend card): a picker of the installed backends, then that backend's configuration form, which is verified against the provider before it is stored. There is no admin screen for it; the identifier of a zone's backend appears in the Backend column of DNS Publication Failures.
The five backends
| Backend | Identifier | Served by | Needs | DNSSEC |
|---|---|---|---|---|
| Built-in | builtin | This server's name servers (dns1., dns2.<server hostname>). | Nothing. | On or off, NSEC or NSEC3, zone transfer ACL. |
| PowerDNS | powerdns | Another PowerDNS, through its HTTP API. | The API endpoint (ending in /api/v1/servers/localhost/), its API key, optionally the name servers to publish and whether to store the panel's markers in RRset comments. | As the built-in. |
| Cloudflare | cloudflare | Cloudflare's name servers. | An API token; an account ID when the token may create zones. Otherwise the zone must already exist at Cloudflare. | On or off, NSEC only; NSEC3 is refused. |
| deSEC | desec | deSEC's name servers. | An API token. | Always on; a zone cannot be unsigned. |
| Manual update | manual | Whoever the domain is delegated to. | Nothing; optionally the name servers to check, for a domain being staged at a new provider before the delegation moves. | None. |
Built-in
The PowerDNS the elpan-dns package runs, reached over a loopback control
port. The panel mints the API key itself, through a privileged helper, and
stores nothing in the zone: a rotated key is picked up on the next
connection. Everything in How DNS publication
works describes this backend first.
PowerDNS
Any other PowerDNS with its API enabled. The panel checks the endpoint and key when the zone is configured, and refuses a zone that PowerDNS already holds as a slave zone, since that is served from a zone transfer and not from the panel. The API key is stored with the zone.
Cloudflare
Cloudflare's unit is the record, so a write is a per-record reconciliation through its batch endpoint, in batches of 200. The apex NS records are Cloudflare's, assigned and not overwritable. TTLs are clamped into 60–86400 on the way out, and a proxied record stores a TTL of 1. The Cloudflare Proxy tab the backend adds to the zone is where the account holder turns proxying on per record; it is the one setting the panel carries for this backend without interpreting it. The API token is stored with the zone.
deSEC
deSEC signs every zone and the panel cannot turn it off, so the picker says so before the first publication rather than after. deSEC enforces a minimum TTL per domain (3600 s ordinarily) and refuses a lower one rather than clamping it, so the refusal reaches whoever chose the TTL as a publication failure. It also throttles writes, at 300 a day per domain, which is why a converged zone is never rewritten. The API token is stored with the zone.
Manual update
For a domain served by a registrar's DNS, a corporate name server, or a provider nobody has written a driver for. The panel works out what the zone should hold and asks the live DNS, directly at the zone's authoritative servers and never through a resolver, whether it does. What is left over is the account holder's list to type at their provider; each row says Waiting for you, Still waiting for you after a day, or In the DNS once it is seen.
- Outstanding rows are checked every five minutes with the rest of the publication queue; rows already seen are re-verified once a day, and a record that disappeared or changed at the provider goes back on the list. Check now on the zone's publication queue re-verifies the whole zone (20 times an hour per account).
- The delegation is observed, never echoed: the NS records the panel publishes for the zone are whoever answers for it, not what the configuration says to check.
- There is no secret, and nothing is written anywhere.
What it gives up:
- Wildcard certificates. A wildcard needs a DNS-01 challenge, which needs a record written into the zone. The account form and the certificate command refuse a wildcard on such a zone and say why; per-name certificates are unaffected.
- Deletions. The panel cannot enumerate the zone, so a record the provider serves and the panel does not publish is never noticed. The zone is the account holder's; the panel is a checklist, not an authority over it.
- DNSSEC, the zone transfer ACL and per-zone settings. Not offered.
A zone on this backend is not listed under Zones Behind on DNS Publication Failures: its outstanding rows are a to-do list, not a fault.
The mirror
A zone that chose another backend is also kept on the built-in one. Every write runs once per target, the zone's own backend first and the server's as a mirror, each diffed against its own state. The mirror is reduced: it carries the records and the SOA policy, never the signing, the transfer ACL or the other backend's settings, because two backends cannot both sign one zone.
It is what makes moving back a delegation change and one sweep rather than
a migration, and it keeps a standby copy on the server's own name servers
meanwhile. dns:inspect <zone> <name> <type> --mirror reads that copy.
Switch a zone to another backend
Storing a new choice records the change, and a worker carries the zone over: it configures the backend (which creates the zone there if it does not exist), refreshes the delegation so the apex NS records are regenerated for the new name servers, sweeps the whole zone, and reads the DS records back. Every record set's published mark is withdrawn first, so the new backend's sweep starts from nothing claimed.
The panel deletes nothing at a backend a zone leaves, and nothing at the backend a deleted zone had chosen: that zone is in the account holder's provider account, and it is theirs.
How the panel decides that a zone and its backend agree, and
dns:republish --verify, which compares the records themselves, are in
How DNS publication works.
The panel offers every record type it knows on every zone. One the zone's backend cannot store is marked in the type picker, warned about at creation, and labelled Not supported on its row for as long as that is true. The record is kept, and published the day the zone moves to a backend that takes the type.