Important Changes in PowerDNS Authoritative Server 4.2.0
Hello PowerDNS user,
as the year draws to an end, we are preparing for the release of a new version of the Authoritative Server (and the Recursor – stay tuned for more news in that area). This release (4.2.0) will see some changes that may affect your usage of PowerDNS. Please read, or at least skim, this article to make sure you will not be surprised when you upgrade.
If, after reading this, you have questions, please reach out to us via our mailing list or IRC channel. If you feel you’ve found a bug or other problem, we’d love a ticket on our GitHub repository.
Autoserial
Since forever, PowerDNS has supported a badly-documented feature called ‘autoserial’ which allowed a database backend to generate a serial on demand, when the serial inside the SOA record was set to zero. This feature was never documented properly and most deployments we have seen of it turned out to be broken in key areas. Supporting this feature also means we have bugs around the handling of the valid serial number zero in zones that do not want autoserial.
Over the last few releases, PowerDNS has gained robust HTTP REST support, and a mature implementation of RFC 2136 DNS Update. For the command line user, pdnsutil increase-serial is a simple way to increase serials on zones after updates.
Because autoserial was hard to use, rarely did what people wanted, and because its presence prevents us from fixing other bugs, we have decided to retire the feature now that several alternatives are available.
Builder/packaging changes
Between 4.1 and 4.2, we have replaced our old package building infrastructure with a new one, based on pdns-builder. While the idea is that most users will not notice this transition, there may be unintended changes.
Our Debian/Ubuntu packages no longer use ucf.
Our ./configure script inconsistently used --enable and --with. This has been fixed; downstream packagers may need to adjust their packaging.
Lua
Around the development of the LUA record type (more on that in a separate post), some of the Lua handling in the Authoritative Server has been refactored. If you have any existing Lua scripts in your Auth server, please make sure they still work correctly after upgrading to 4.2.
GOST
Following RFC6986 which deprecates the usage of GOST R 34.11-2012 generally, and anticipating the publication of Algorithm Implementation Requirements and Usage Guidance for DNSSEC which intends to move DNSSEC ECC-GOST support in signers to the ‘MUST NOT’ category, support for both ECC-GOST signing and GOST DS digests has been removed. In the unlikely situation that you have domains signed with ECC-GOST, you will need to roll their algorithms before upgrading to PowerDNS Authoritative Server 4.2.
PowerDNS Blog 
Hello,
As I am still rather new with PowerDNS terminology, I wanted to make sure that the Autoserial change will not affect domains with metadata attribute “SOA-EDIT” set to “INCEPTION-EPOCH”.
We currently have domains with “0” serial in SOA record and domainmetadata attribute “SOA-EDIT” set to “INCEPTION-EPOCH”. This allows the served serial to correspond to the highest “change_date” row value among the records of the corresponding domain_id.
Can you confirm this behavior will persist in PowerDNS 4.2 series? Otherwise, what are the alternatives w/o relying on ‘pdnsutil’ command line (we would like to rely only database operations).
Thanks in advance.
Guillaume
Hello Guillaume,
the autoserial change will not affect SOA-EDIT; however, the autoserial change does mean that 4.2 will ignore your change_date column, and your 0 serial should lead INCEPTION-EPOCH to always set your serial to the last signature rollover (the most recent Thursday). This means changes will only be picked up by slaves on the next Thursday. You will have to switch your serial management to pdnsutil, our HTTP API, or an SQL UPDATE to the SOA record content field in the records table.
Regards,
Peter
Hello and thanks for your reply. This is indeed what we have experienced while running tests with 4.2.0-alpha1. We have updated our workflow so we manually update the SOA via SQL UPDATE and this is working fine.