A number of years ago, I became the manager of a small group within Networking supporting software and services including DNS. As I learned about what I had inherited, I wanted to run away screaming. The problem with DNS is that even bad DNS that works most of the time, at least when no one is making changes, is better than no DNS, so I couldn't chuck it out the window and start over. As the DNS person said, Major changes will be like changing the tires on a car ... while it's racing.
We were running several different versions of ISC BIND on a large number of servers that were authoritative for around 1600 zones but also recursive for anything else for on-site queries. We managed around half of the zones, while one unit managed around a third from their hidden masters and transferred to us for public queries. Most of the remainder of the zones were in Active Directory (so "junk" arrived via those zone transfers, unfortunately, so all checks and warnings had been disabled, scarily enough). Some departments managed their forward records, but due to the historical nature of some VLANs making subnet delegation difficult, we still maintained the reverse records. When I joined the story already in progress, we had organic growth in need of pruning, like chained CNAME references.
You should be cringing by now. I won't even mention extraneous glue records and other oddities. It was dangerous to make changes without knowing the history of the files you modified. I believe you should be able to make valid changes without worrying about DNS crashing! The original architecture had been designed when DNS was young, and no one had stepped in to re-evaluate what we had, how we should do it going forward, and how to get there.
There was a clean-up. All servers were updated to run the same version of ISC BIND. Chained CNAME references were removed (some of which had customer impact due to ancient software that should have been upgraded, but it wasn't our place to dictate that). Extraneous glue records were removed. Most major warnings were corrected so that it was reasonable to view syslog again. This took years for the number of zones, and for the number of customers who needed to know in advance in case that particular clean-up had an impact. We still had records I didn't want in our DNS, but we have a policy of doing what the customer requests if possible.
However, we still needed a path forward that wouldn't require detailed institutional knowledge, and wouldn't have the fragility of BIND where an error in one zone file (among thousands!) would prevent the process from running. I have a fondness for *nix and databases, but I didn't have an initial budget.
I looked at Wikipedia for a comparison of DNS server software. Features in BIND that we were already using were authoritative, recursive, IPv6, and free. Additionally, Security asks annually about DNSSEC, so I needed support for that too. As you can see, that just leaves BIND and PowerDNS. The more I looked at PowerDNS, the more intrigued I was.
However, I also needed an interface to PowerDNS that wasn't poking the database directly! So I looked at:
pdnsutil, which is a command-line tool that looks like you're editing BIND files, but there's feedback on potential errors when you save so it's better than what we were doing!
I made a list of desired features, and quickly discovered that one feature eliminated all front-end tools except PowerAdmin: the feature to add, optionally, a reverse (PTR) record when entering a forward record (A or AAAA). However, some other projects also hold glimmers of hope for that feature!
For the moment, my favorite front-end for PowerDNS is
pdnsutil. It lacks my "pet" feature, but it's extremely familiar for my BIND experience. If a GUI is needed, I recommend (and sometimes use) PowerAdmin. However, I'm keeping an eye on nsedit (that issue was recently resolved, so I need to test again!) and the other projects.
If you want to learn PowerDNS, I recommend PowerDNS documentation, and the book Alternative DNS Servers by Jan-Piet Mens.