What's New in 4.6.0¶
Warning: In development. 4.6.0 is the
developbranch and has no tag yet. This page lists what has landed so far and grows until the release is cut. The latest release is v4.4.1, and 4.3.x remains the stable line recommended for production.
4.6.0 so far is a release of small operational knobs and a large internal cleanup. Secondary zones can be pulled from their primary on demand, an installation can stop bumping the SOA serial on saves that change nothing, and every setting from earlier releases can now be set from a Docker environment variable. Underneath, the web forms and the API were moved onto the same service layer, which closed a number of gaps where the two behaved differently.
Highlights¶
Retrieve a secondary zone from its primary¶
The edit page of a Secondary zone offers Retrieve from primary next to the primary IP. It asks PowerDNS to transfer the zone right away instead of waiting for the next SOA refresh, and reports whether the request was accepted. The button appears only with the PowerDNS API backend, because the SQL backend has no way to trigger a transfer, and it needs the zone meta edit permission.
See Zone Management.
Optional serial bump on unchanged saves¶
Saving a zone with no record changes has always bumped the SOA serial, and still does by
default, because that is how operators force a NOTIFY. dns.bump_serial_on_unchanged_save
lets an installation opt out: with false, a zone save or single record edit that changes
nothing leaves the serial alone and says so. A save that does change a record bumps once, as
before. In Docker the setting is PA_DNS_BUMP_SERIAL_ON_UNCHANGED_SAVE.
See DNS Settings.
Every setting reachable from Docker¶
Twelve settings from 4.3.0 and earlier had no environment variable, so a container had to
mount a settings.php to change them. They now have one each: the database charset, the
password policy's special-character set, the lockout IP whitelist and blacklist, the two
permission template visibility flags, the dashboard statistics toggle, the four avatar
settings and the pinned record types.
See Docker and the full table in DOCKER.md.
Stale zone saves keep your edits¶
When another user saved the zone first and the conflict strategy rejects your form, the
editor now re-renders with your submitted records and comment in place, marks the rows that
differ from what the zone holds, and lets you re-check and resubmit instead of retyping.
With the last_writer_wins strategy a stale form is saved as before.
See Zone Management.
Also in this release¶
| Change | What it does | Where |
|---|---|---|
| Zone type change needs the target grant | Converting a zone into another kind requires the same permission as creating one of that kind: zone_slave_add for Secondary and Consumer, zone_master_add for the rest |
Permissions |
| One permission rule for zone actions | A zone action is granted when any template the user holds, directly or through a group, grants it and the user owns the zone. The stricter hybrid rule that required the grant to come from an owning group is gone | Permissions |
| Primary zone over delegation records | A primary zone can be created where the parent only holds delegation records for it (#802) | Zone Management |
| Unknown SOA-EDIT-API values rejected | The add-zone form refuses a serial policy value it does not know instead of silently dropping it | DNS Settings |
| Record edit and comment in one request | On the API backend a record edit and its comment reach PowerDNS in a single call (#1556) | PowerDNS API |
| API user passwords follow the policy | Passwords set through the API are hashed with the configured algorithm and must satisfy the password policy, the same as the web form | Password Policies |
| API zone creation matches the web form | Zone names are converted to punycode, the third-level check applies, and a template the caller may not use is refused | API Overview |
| API records stored as punycode | Record names and content are normalised to punycode and duplicate records are refused, matching the web editor | API Overview |
| Signed zones stay consistent over the API | Record writes through the API rectify the zone, so DNSSEC ordering data is not left stale | DNSSEC |
| Last super admin protected | The last remaining superuser cannot be deleted, from the web or the API, and record comments are cleaned up when a zone is deleted | Users and Roles |
| API events attributed to the key | Audit entries for API requests name the API principal, and the SAML logout entry keeps the acting user | Database Logging |
| Request validation rules enforced | Length, list and allowed-value rules on form fields are checked instead of being dropped | |
| Zero session timeout rejected | interface.session_timeout = 0 is refused at startup instead of logging every user out on their next request |
Basic Configuration |
| 768-bit DNSSEC key option removed | No algorithm accepts it, so the add-key form no longer offers it | DNSSEC |
| API-mode reverse zones listed correctly | With the API backend, reverse zones are listed under their canonical id | PowerDNS API |