Skip to main content
Diagnostics looks at a DNZ install for the usual mistakes: port 53 taken, a zone the registrar doesn’t point at DNZ, a DS record that breaks DNSSEC, a secondary that stopped transferring, a certificate about to expire, a clock that is off, a resolver open to the whole internet. Each finding says what was seen and how to fix it, with commands or settings to paste.
Diagnostics checks DNZ’s own setup. It was called Health check before v2.0 and is not the health check of an upstream, which decides where visits go.
It runs in three places:
  • Settings → Diagnostics (superadmins): the findings, Check now, muting and the settings. A badge in the header shows how many findings need fixing.
  • dnz doctor in the terminal, --json for scripts. When no server answers (often because port 53 is taken), it checks the machine it runs on by itself.
  • On a schedule (hourly): findings that turn bad go to the notification providers subscribed to health_check, and again when they are fine.
Each finding is fail (broken), warning (fix it), info (worth knowing), skipped (couldn’t tell, e.g. no internet to ask) or ok.

Checks of this server

In a cluster each node checks its own machine; its findings carry its name.

Checks of the install

Zones under .local, .lan, .internal, .home.arpa, .test and the like, and reverse zones of private ranges, are left out of the delegation checks. Those ask public resolvers to find the parent zone, then the parent’s nameservers directly, without recursion, the way a resolver walks down from the root.
The delegation checks run from DNZ itself. Behind NAT without hairpinning, DNZ’s own public address can time out even though the internet reaches it; check from outside with the dig commands the finding gives. A firewall or filtering proxy that answers DNS in the public resolvers’ place makes these checks skip, and the finding says so.

In the terminal

dnz doctor exits with status 1 when a check fails (warnings don’t), so it fits a cron job or a CI step after a deploy. The ids of what needs fixing:

Update badge

While a newer DNZ is out, an Update badge shows in the top bar for superadmins (and anyone allowed to manage monitoring). It opens the running and latest version, a link to the release notes and copy-paste upgrade commands for Docker and the binary. Not now hides it in that browser until the next release. It reads the same once-a-day release check as the version finding, so it follows the Release check setting below; with the check off there is no badge.

Schedule, alerts and muting

Every node runs the schedule for its own machine; the cluster’s leader also checks the install and sends the alerts, so each goes out once. One message lists what turned bad, with the fixes; another follows when it’s fine again. Subscribe a provider to Diagnostics finds a problem (health_check). Mute a finding you accept (a resolver meant to be public, a zone you don’t delegate yet): it stays listed, greyed out, but leaves the badge, the counts and the alerts.

Settings

Under Settings → Diagnostics, or dnz settings diagnostics (dnz settings health-check, its old name, still works).

Metrics

With Prometheus metrics on: dnz_health_findings{status} (findings by status, muted ones left out), dnz_health_finding_problem{id, check, status} (1 per finding that needs fixing) and dnz_health_last_check_timestamp_seconds.