Skip to content

Database Consistency Check

The consistency check looks for zones and records that are structurally broken - a zone nobody owns, a slave zone with no master, records left behind by a deleted zone - and offers a one-click fix for most of them. It is reached from Tools → Database Consistency Check (/tools/database-consistency).

Database Consistency Check

Enabling it

The page is disabled by default. Turn it on in config/settings.php:

'interface' => [
    'enable_consistency_checks' => true,
],

Without this setting the menu entry does not appear and the page reports that consistency checks are disabled.

Access is restricted to administrators (user_is_ueberuser). There is no separate permission, so it cannot be delegated through a permission template.

What it checks

Each check reports success, a warning, or an error, and the summary panel at the top counts the total issues, errors and warnings.

Check Severity What it finds Available fix
Zones without owners Warning Zones with no user owner Fix assigns the zone to you; Assign all to me does the whole list at once. From 4.6.0, with dns.adopt_zone_owner_from_account on, a zone whose PowerDNS account names a user goes to that user instead; otherwise, or when that user is at their zone limit, it still goes to you
Slave zones without masters Warning Slave zones with no master IP set, which can never transfer Delete the zone
Orphaned records Error Records whose zone no longer exists Delete the record
Duplicate SOA records Error Zones carrying more than one SOA Fix keeps the first SOA and deletes the rest
Zones without SOA Error Zones missing an SOA record entirely Fix creates a default SOA
Zones without a canonical ID (4.5.0+) Warning API backend: zone rows left without a canonical zone id by an interrupted zone creation Fix repairs the row; Repair all does the whole list
Zone IDs shared by two zones (4.6.0+) Warning Zone ids two zones share in API backend mode, with both zone names and the number of ignored owners and group grants None - report only
Zones without a stored name (4.6.0+) Warning SQL backend: zones with owners, group grants or API key restrictions but no zone row carrying their exact name, which a switch to the API backend would add again without them Fix stores the name from PowerDNS, adding an ownerless row for a zone that has none. A row the API zone sync added before 4.6.0 that holds the name and that nothing uses is removed first; Repair all does the whole list
Group assignments under a zone row ID (4.6.0+) Warning Group assignments made through the API before 4.6.0 whose stored id is a migrated zone's row id and names no zone now None - report only; remove the assignment and assign the zone again
Zone names differing only in letter case (4.6.0+) Warning Zones whose names match except for letter case, such as Example.com and example.com, with their ids. PowerDNS treats them as one name None - report only; delete the zone you do not use
API key restrictions naming a deleted zone (4.6.0+) Warning API keys whose zone restriction names a zone id that no longer exists Fix points the key at no zone; Fix all does the whole list
Record names with uppercase letters (4.6.0+) Warning Records whose stored name contains uppercase letters Fix lowercases the record name and the comments on its RRset; Fix all does the whole list

Every fix is a POST protected by a CSRF token, and destructive actions ask for confirmation first.

Behaviour in API backend mode

The checks run against whichever backend is configured, so they work in API backend mode as well as against the database.

Four differences apply there:

  • The orphaned-records check is skipped and always reports success. PowerDNS owns the zone-to-record relationship in API mode, so the condition cannot arise.
  • If the PowerDNS API is unreachable, or any zone read fails partway through, the page reports a single error instead of results. This is deliberate: a partial read could otherwise make a healthy zone look like it was missing its SOA.
  • The shared zone id check can only find something here. A zone created in API mode and a zone migrated from SQL mode can get the same id; extra owners and group grants on that id are ignored until an administrator separates the zones. See Zone IDs Shared by Two Zones. In SQL mode every zone has its own id, so the check always reports none.
  • The stored zone name check only applies to SQL mode, where it prepares a later switch to the API backend. The zone sync names every zone it keeps, so in API mode it always reports success.

The letter case check can only find something where the backend stores two such names: SQLite, a MySQL database with a case-sensitive collation on the domains table, or API mode. The stock PowerDNS MySQL and PostgreSQL schemas refuse the second name, so there it always reports none.

When to run it

Consistency problems are usually the result of something interrupted - a failed bulk delete, a restored backup, a partial migration, or direct changes made in the database rather than through Poweradmin. It is worth running after any of those, and after upgrading across a major version.

Zones without owners are the most common finding. They are harmless to PowerDNS but invisible to non-administrator users, since Poweradmin scopes most views by ownership.