I use PowerDNS (pdns) for running DNS servers. For the primary nameserver running on a machine big enough to run a MySQL server, I use the MySQL backend for pdns. For backup nameservers, I like to be able to use a much less powerful machine, which means not running a fully-fledged SQL server. The obvious solution is to use the SQLite backend (gsqlite3) for pdns. These backup nameservers are generally set as superslaves, meaning that they'll accept any domains handed to them by the primary nameserver, rather than only accepting records from the primary nameserver for domains which it is explicitly set as a slave for (so upon registering a new domain, only the primary nameserver has to be told about it).

In a perfect world, everything would work. Unfortunately, in my experience, pdns with the gsqlite3 backend doesn't like being a superslave. If you try it, then upon being handed a new domain by the supermaster, the superslave gives the following error:

Backend error: Database error trying to insert new slave 'example.com':
Error while retrieving SQLite query results

Mailing lists suggest that this is due to a bug in the gsqlite3 backend, and that a solution is to use the opendbx backend for pdns, and have opendbx use its sqlite3 backend. This is exactly what I end up doing, so you go through the process of downloading and building OpenDBX, then recompiling pdns with support for the opendbx backend rather than the gsqlite3 backend, and rewriting the pdns configuration file to point it at the SQLite database through OpenDBX. Supposing you do all this correctly, pdns will launch, then complain about a missing d.auto_serial column, then exit, which is when you remember that the opendbx backend wants your tables to be set up slightly differently to what the pdns documentation tells you, so you remake your SQLite database using the commands listed on the OpenDBX site. Now pdns launches successfully and stays running, but upon trying to transfer in a domain, the following error occurs:

[OpendbxBackend] Database connection (write) to '/var/pdns/' succeeded 
Can't determine backend for domain 'example.com'

At this point, you're nearly ready to give up, but you decide to try one last thing inspired by the message just before the error: the user which pdns is set to run as has read / write permissions to the SQLite database file, but doesn't have many permissions on the directory containing the SQLite database file (which perhaps it needs to create copies of the database file for transaction support, who knows). Upon making the pdns user the owner of the directory containing the SQLite database, things finally work:

AXFR started for 'example.com', transaction started
AXFR done for 'example.com', zone committed

That is today's tale of woe. May it assist me in the future when I next commission another backup nameserver.