Skip to main content
The health check 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. It runs in three places:
  • Settings → Health check (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:

​
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 Health check finds a problem. 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

​
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.