DNS and system configuration vs. application data.

There's a rough distinction to be made between system configuration data and application managed data. The former is altered by the development / operations staff, and the latter is altered by application users. The former is typically maintained in a revision control repository and deployed to the live systems using configuration management tools such as rdist or puppet; the latter is maintained on the live systems by the application from which it is backed up. The former tends to be more ad hoc and the latter more standardized.

So for email the application data includes messages in flight (SMTP/LMTP) or in store (IMAP/POP), users' sieve filters (MANAGESIEVE), and the shared address book (LDAP). [I mention the protocols to emphasize the standardization.] System configuration data includes things like which domains are hosted where, system aliases, central filtering and access control rules, and suchlike. The distinction is rough because in an environment that is more ISPish than corporate, big chunks of system configuration get delegated to customers and sold as "virtual mail domains", with their own custom management applications in place of sysadmin tools, and SQL or LDAP database storage.

The DNS is more like a system configuration component than a user-facing application. Even so, it's a bit surprising that BIND has remained so firmly based on traditional flat files (at least, superficially). But in fact for a corporate environment (with one frequently-updated main zone and not a lot of churn in which zones are being served) the DNS has some really nice application data management features. In fact it had loads of NoSQL buzzwords before NoSQL was cool. It's a distributed replicated in-memory database with eventual consistency. The combination of UPDATE, NOTIFY, and IXFR mean that the lag between a user requesting a modification and it becoming visible at the slaves can be tiny. UPDATE itself has very nice transactional semantics which allow you to implement read-modify-write operations with optimistic concurrency. Swish.

It isn't actually too painful to bridge the gap between static zone files in revision control and live zones managed by BIND. Here's a little tool called nsdiff which does the job. If you are running on the master server you can just pipe the output into nsupdate -l. (This is not much harder than updating the live zone file in place and running rndc reload.) Note that if the diff is too large, nsdiff breaks it up into multiple update operations - perhaps it should have an option to fail if it can't use a single atomic transaction.

Whereas dynamic updates have been around for many years, BIND has only recently become able to incrementally add and delete zones from its configuration, as opposed to re-reading the entire thing to find out which zones it should serve. This is a bit surprising since BIND configuration updates have been a pain point for ISPs for a very long time. Other nameservers with more accessible database backends probably make provisioning rather less clunky than my little addzone-master addzone-slave delzone scripts.

It might be interesting to see what comes of the IETF DNSOP work on standardized name server management. So far there is just a requirements document but sadly not much sign of follow-up work.