Skip to main content
These commands look after the server itself rather than its DNS data. For the settings themselves, see Configuration.

​
Configuration

  • config example prints a commented config file with every setting. Start a new /etc/dnz/dnz.toml from it.
  • config show prints the effective value of every setting and where it came from, with its file key next to its environment name.
  • config check only validates the configuration. Unknown keys in the file are errors, so typos don’t go unnoticed. It also says which database the configuration points at (SQLite, Postgres or MySQL), without the password.
DNZ reads the config file first, then the environment, then flags; a later one wins. Pass another file with -c / --config or DNZ_CONFIG. See Configuration for the full order and every setting.

​
Move to Postgres or MySQL

Unlike the other commands, this one works on the databases directly, on the machine DNZ runs on. Stop DNZ first. It brings the SQLite file up to this version’s schema, creates DNZ’s tables in the target and copies every table, printing the rows of each. The target must have no users or zones yet. Afterwards the ids continue after the copied ones and the row counts are compared. Keep the SQLite file as a backup, set database.url / DNZ_DATABASE_URL to the new database and start DNZ. See Database.

​
Health check

Exits with status 0 when this machine’s server answers (GET /api/health), so it works as a Docker HEALTHCHECK or a monitoring probe.

​
Doctor

dnz doctor runs the health check: port 53, zone delegations (NS, glue, DS, lame nameservers), secondaries, certificates, the clock, disk space, the DNZ version and weak settings, each finding with its evidence and a copy-paste fix. Superadmin.
When no server answers, dnz doctor checks the machine it runs on by itself: whether DNZ can bind its DNS port and what holds it (systemd-resolved, dnsmasq), disk space, the clock and the version.

​
Version

​
Factory reset

A factory reset erases everything on the server:
  • zones and records
  • users and divisions
  • API tokens and update keys
  • proxies and replication
  • filtering, notifications and settings
  • logs
The server goes back to first-run setup (dnz setup, or the web UI), and your saved session for it is forgotten. The config file and the environment stay. With DNZ_ADMIN_PASSWORD set, that admin is created again.
This can’t be undone. Take a backup first if you might need anything back.
Only a superadmin can do it. It asks you to type RESET; --yes skips that, for example in scripts. The dashboard has the same under Settings → General → Factory reset.