I do love me some BIND-style files.
They are direct. Open the file, read the zone, change the record, check the syntax, reload the service. If you know DNS and you know the server, there is very little mystery between the configuration and the result.
The problem is that we want to automate more and more of it.
I have been at Shutterstock for less than two months, and one of the systems I am setting up is PowerDNS with a MySQL backend. Instead of treating zone files as the final source, the records live in a relational database. Secondary servers can follow through MySQL replication. A web interface gives the team a way to manipulate the data without making every change an edit to a text file on one machine.
This setup should be easier for the team and applications to manage.
The first pass is up. I had to replace the administration interface with a more stable version before it handled the database properly. The database has been solid through the tests. Recursion and authoritative zone serving appear to work. The VPN is pushing DNS and search domains properly to Mac clients.
Linux still needs a real check.
That last part matters because "works on my machine" can look especially convincing with DNS. A local host-file entry, cached response, VPN setting, or search domain can make one laptop look correct while another client is still asking the wrong resolver. I asked the team to test whether Linux clients receive the same settings and to run a direct lookup against the new domain.
The technical decision is not really PowerDNS versus BIND. BIND can run an enormous and reliable DNS environment. I know it well. The decision is how we want people and software to change records as the company grows.
A text file is easy for one administrator. It becomes harder when several people need access, an application wants to create records, secondary systems need consistent state, and changes need a record.
Now the schema matters. Replication matters. The administration interface matters. Permissions matter. A bad query can create the same outage as a bad zone edit, only faster. The system needs backups, tests, and a clean way to recover the state. We need to know which component is authoritative and what happens when the web interface is unavailable. We also need changes to arrive on secondary servers predictably instead of depending on somebody to copy a file and remember the reload.
Still, the database gives us a better center for the system we are trying to build. Records become data that applications can manage through defined paths. Secondary DNS can follow a replication model the team already understands. The interface can reduce the number of people who need shell access simply to add or inspect a record.
Nobody outside technology needs to know we moved DNS records into MySQL. The useful results will be faster configuration for new environments, consistent internal resolution over the VPN, and a clearer record of changes. A DNS outage would affect everybody, so the migration still needs careful testing.
I sent the setup note on Friday with the internal address, host-file instruction, and login. Two days later I sent the useful version: the stable interface is installed, the database is working, recursion and zone serving look good, and here are the client tests still needed.
The first setup email also included a credential. I do not want that to become the regular access process. Access controls, backups, and a cleaner deployment path still need to be completed before more people depend on the system.
For now, PowerDNS is running. The database, recursion, authoritative zones, web interface, and Mac VPN settings have passed their first tests. Linux client testing, access cleanup, backups, and a recovery test are next.
The secondary servers also need to be checked against the MySQL replication path before the migration is complete.
-Chris