3 ms·

Greetings from Bytemark, we are contemplating much the same thing right now. We have our old content DNS system (http://www.bytemark.co.uk/support/technical_do

by mattbee 12y ago

Greetings from Bytemark, we are contemplating much the same thing right now. We have our old content DNS system (http://www.bytemark.co.uk/support/technical_documents/dnsc http://www.bytemark.co.uk/support/technical_documents/dnsc) which just lets you upload tinydns data via rsync (since 2003). Based on tinydns, so it's been completely rock-solid stable but missing more and more features as time went on (IPv6 is in, but DNSSSEC is a long way off). Our challenge is to add / augment this to allow sane control panel access for people that want t ouse it and not proliferate databases or logins. We have a rough idea of what to do, as maybe you do too, though we will likely have to make people choose between "old" and new type logins But the idea will remain the same -upload a nice simple text file of records, becomes live straight away. tinydns syntax can certainly be transformed from other formats pretty easily... What're you working on then?

stevekemp 12y ago
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.

by mattbee 12y ago

stevekemp 12y ago

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.