NETWORK & DOMAINS

DNS providers and records

Connect Cloudflare or another provider so DockBoard can create and check the records itself.

You can always point a domain at DockBoard by hand, in your registrar’s panel. Connecting a DNS provider replaces that with something better: DockBoard writes the records itself, checks them, and cleans them up when a domain goes away.

Supported providers

Provider	Credential
Cloudflare	An API token scoped to Zone → DNS → Edit on the zones you want managed.
Namecheap	API user, API key and the IP allow-list Namecheap requires.
OVH	An application key/secret/consumer key triplet.
Gandi	A personal access token.
PowerDNS (self-hosted)	A PowerDNS instance DockBoard runs for you — you become your own authoritative nameserver.

Credentials are stored encrypted and never returned in plaintext. A provider is tested at the moment you save it, and can be re-tested at any time — a connection that has never tested successfully shows as failing rather than staying quietly broken until a domain needs it.

Scope the token to DNS editing on the zones you actually host here. A full-account API key in a panel is a much larger blast radius than the job requires.

Personal or project-scoped

Like registries, a DNS provider belongs to whoever added it and is optionally pinned to a single project. Personal for your own account’s token; project-scoped for a client’s zone or a credential that belongs to the team rather than to you.

Attaching a zone

01Add the provider. DockBoard tests the credentials immediately.
02List the zones visible through that API and attach the ones you want DockBoard to manage.
03Add domains as usual. Records are created for you instead of being copied by hand.

An attached zone also gets a record browser: list everything in it, create or update a record, delete one. Handy for the TXT a payment provider wants, or the MX your mail server needs, without leaving DockBoard.

What DockBoard writes, and what it removes

Adding a domain to an application publishes the records that point it here. Deleting the domain retracts them — DockBoard removes what it created rather than leaving a public record aimed at a server that no longer serves that name.

A dangling record is not cosmetic. A name that still resolves to an address you no longer control is a subdomain takeover waiting for whoever gets that address next. Retraction is the point of letting DockBoard own the record.

DockBoard never writes an NS record on your behalf. Delegating a zone is a decision with consequences your panel cannot undo for you, and a nameserver is never the thing an automated sync should be guessing at.

Checking a domain actually resolves

Each domain shows whether its records currently resolve to this platform. The two things that go wrong, and look identical from a browser:

Propagation. The record is correct and the world has not caught up yet. Wait — minutes usually, up to the previous record’s TTL.
A record pointing somewhere else. Often a leftover from a previous host, or a proxy sitting in front. That one never fixes itself.

Lower the TTL to a few minutes before a migration, not after. A 24-hour TTL set the day you move is 24 hours of split traffic you cannot shorten retroactively.

Running your own nameserver

DockBoard can run PowerDNS for you and use it as a provider like any other — the difference being that the zones live on your machine rather than at a third party.

To answer queries from the public internet it must listen on port 53, which is a platform-wide exposure — so arming it is an explicit admin action (servers:manage), not something a project member can flip. The nameserver hostnames DockBoard advertises come from one explicit setting and are never inferred: guessing them would publish nameservers that do not answer.

Self-hosting authoritative DNS means your nameserver being down makes every domain it serves unreachable — including the dashboard you would use to fix it. Keep a second nameserver elsewhere, or stay on a managed provider.