I suspect you could solve your problem ("provide web-interface to DNS") reasonably easily without moving away from tinydns. If you used a sneaky second access

I suspect you could solve your problem ("provide web-interface to DNS") reasonably easily without moving away from tinydns. If you used a sneaky second access mechanism (HTTP, say) to get the hosted/live records from your upload-host you could wrap that into a form with fields and select-boxes for record-types (since tinydns is so trivial to parse). (If you were to just expose the actual tinydns file then the whole thing is trivial of course, but user-error is more likely.) Once you have some user-interface then applying changes goes in the same direction, process the form submission, then put back the modified records to the central location, and trigger a rebuild of the binary records. -- My current prototype allows a complete zone-file to be POSTed to a HTTP service, and then written out to a tinydns file _or_ uploaded to Amazon's route53 service. Similarly you can query a zone and retrieve back an array of records. Each record has an ID, a type ("A", "NS", "AAAA", "MX") along with the associated data. The point where I've started to take a step back and think things over is the case of adding/editing a single record. Because each record has an ID you can trivially say /zone/example.com/delete/$id or POST to apply an update. But allowing operations to be applied to a single record complicates things somewhat, and that was the point where I started considering using git as the storage back-end. That would allow historical tracking, and interesting things to be done - especially if you exposed the actual store too.