I worked on slave DNS support in the dev-dns branch tonight. I had trouble with the service stuff, but I got over it and I can happily announced that we crossed a significant milestone in DNS support:
We now have basic DNS support in Aegir!
There is still a ton of work to do, but it is the bare minimum for a basic setup:
- Creating a site creates a "A" record (and a zone, if necessary)
- Deleting a site deletes that record (and that zone, if empty)
- Zone creation and deletion are configured on slave servers
- Basic commandline utilities exist to manipulate the zonefiles
- Manual edits to zonefiles are not kept
This first step aims to provide really basic DNS support for people. It doesn't feature a "host my mail at google" button or a "register this domain" form. It will not make coffee for you. In fact, there's almost no visible UI for now. It is meant as a first, non-intrusive step for sysadmins and developpers tired of messing around with their /etc/hosts file.
There are still a few caveats, which I maintain in the dns/NOTES file in git for simplicity. First of all, the slave support is still crude and require some commandline wizardry to be functional (see NOTES). Second, slaves are not tested properly and may have bugs. In fact, the whole thing has been barely tested, so any feedback here would help. Please file real bugs as such in the trackers.
For people that freak out of the idea of a Drupal/Aegir messing with their DNS: don't worry, DNS hasn't become a requirement for aegir. It's just sugar on top! If you don't configure a DNS service, it shouldn't get in your way.
Since the implementation is so young and basic, I guess I need to tell here what's missing. The next steps for DNS are:
- bridge with inter-server migration. this requires placing zones in "warm-standby" by lowering the TTLs and then updating the records when migrating (which is not done at all right now)
- bring back the full zonefile editor from the dead, to allow users to edit zones without going through the commandline
- this implies having a real zone object in the frontend, also for proper access control (if client A has example.com, you probably don't want client B to create www.example.com, right?)
- eventually, we should have a simple vs advanced zonefile editor to allow power users and regular people to edit those zonefiles. dyndns.org and gandi.net are good examples on how this can be done.
- the holy grail here is full registrar support: when somebody blindly enters a non-existant domain, kindly help them register it for them and point DNS to your servers and all
I will not be working on this stuff for a while as I am moving to other targets (mostly LDAP support) for our (Koumbit's) internal/public/secret/i-won't-tell-you-about-it-yet beta. But as part of the AlternD effort, it is certainly something I will revisit within the next year, as Koumbit will migrate more and more services (read DNS, mail, mailing lists, etc) to an Aegir-based control panel (read: CPanel killer in Drupal!).
Oh, and I have posted a quick blurb on the aegir-dev mailing list about the implementation details for people into that kind of stuff. The code still lives on the dev-dns branch (aarggh!) but I will merge it on master as soon as I shake down the last bug (slave servers are not reloaded).

Comments
clarification on how slaves work
Comments on IRC made me think that I wasn't clear enough on the way slave servers were configured. We fully use the standard AXFR protocol: we just configure the slave to pull the master for those zones and that's it. We don't go around editing like crazy on the slave for every record added or removed. The only time the slave is contacted is when a zone is created or destroyed. The rest is taken care of by zone transfers.
Summary of the next steps: in the trackers
I have made a summary meta-issue on drupal.org regarding the next steps to do on the DNS front. This issue is therefore a much better and up-to-date description of the future DNS roadmap than the above.