This week I updates my PowerDNS installation. From version 2.9.21 to 4.0.1. The migration went smooth without any issues. A few minor parameter changes and a database where the data could be transferred without any issues. Me very happy about it.
Today I wanted do the webfrontend for PowerDNS. I used an application with a latest update in 2013. The website does not exist anymore. Time for new stuff to make it a bit easier than giving SQL commands. A list of possible web frontends is given at https://github.com/PowerDNS/pdns/wiki/WebFrontends and because most of my machines do PHP by default I did choose for nsedit.
Nsedit uses the API which is provided by PowerDNS, which come in handy when PowerDNS uses more than one backend for this data. Most of my data is stored in a MariaDB but a few zones are in a different backend. By using the API multiple backends can be queried as the previous application only did read and write directly to the database.
Installing nsedit was a piece of cake, just a untar action and 4 lines of configuration and all was done. Opening a browser to go the webpage and with the default login I was in. A long list of my zones where showing. All happy about it, till I wanted to view the records of a zone and got a nasty “API Error 500: Internal Server Error”.
To make a long story short, the API cannot use SOA records which are perfectly fine for PowerDNS. In PowerDNS the serial number of a SOA record may be 0 (which on query will be filled in by timestamps from all the records of a zone) or a given serial record. The refresh, retry, expire and min TTL are not required to store in every entry in the database. If these fields are not in the data of the SOA record, PowerDNS will add the configured (or default) values when the SOA record is queried.
The API cannot handle this and requires that all data is in the record and will throw an HTTP 500 error if something is missing. The funny thing about this is that the CLI tool to check a zone provided by PowerDNS is giving 0 errors and 0 warning for these zones.
The second issue is with slave zones where the records of a zone are imported. PowerDNS accepted TXT records where the data is not enclosed by “”. Not right by the definitions of the RFC. But no issues by PowerDNS when doing a AXFR. And after the transfer PowerDNS will giveout the records (and even fix then by adding “” to the data). But the API cannot handle these faulty records and will throw HTTP 500 errors when these records are requested.
The API is more restrictive than PowerDNS for data. I can understand that when the API is used for storing data. But when reading data the API should be able to return the same data as which PowerDNS fully accepts when doing its work as DNS server. Did write a small piece of PHP code to check the results. Out of the 108 test zones in this server, 0 are giving errors/warning when they are being verify by the PowerDNS check tool. 79 zones are producing errors when queries by the API.
For the first issue the API must handle the SOA records the same a PowerDNS does when reading If PowerDNS produces (error free) results, so the API must do that. Be more restrictive when writing data thru the API. But still be compatible with the reading action. It is possible (and accepted) to modify the data directly in a backend, just be consistent on when generating errors.
For the second, PowerDNS should not successfully do an AFXR of a zone when there are invalid records for that zone.
And as a bonus, because the above errors, the search function of the API will also break when there are ‘invalid’ records in the database.