We also store our DNS records in a version control repository where all changes
are audited, tested, and tagged before being pushed out to production. This is
real change _control_. What you’re talking about is change monitoring. You
don’t know about changes until after they wreaked havoc without the benefit of
knowing who did it.

The DNS records are stored in plain text in the VCS with a custom grammar that
keeps the records normalized. We define the hostname -> IP address pairing once
with additional meta-data that identifies what zones the forward and reverse
belong to as well as if it should create static DHCP host entries. Using this
we can generate the zone databases on the fly with triggers from a
configuration management system that detects commits to the repository. The
configuration management system also guarantees –within reason– that what is
in the repository is what is on the production boxes. If we want another DNS
server, we setup a minimally configured box, point the CMS at it, and ten
minutes later, it’s serving up zones or anything else we need to have it doing.

I can command the entire thing –without ever touching the production boxes by
hand– with nothing but a text editor, programming environment of choice and a
git/svn client. In fact, with TortoiseSVN, we even have our first-tier user
support staff making changes to the repository. Even if they screw it up, the
changes never make it to production.

You keep talking about the right tool for the job, but if you’re maintaining a
large BIND installation using pico, ssh and for-loops, you’re not following
your own advice. No wonder you like AD.

Frankly, I can’t imagine a scenario where UNIX doesn’t have the right _set_
–not necessarily a single uber one– of tools for any particular job. The
right-tool-for-the-job mantra is usually just personal bias thinly veiled as
pragmatism. If you like MS junk, fine; keep using it. Your experience is still
only anecdotal.