While reading up on dnssec-keygen and other related stuff in order to update my puppet bind module to support DNSSEC transparently, I accidentally stumbled across something in the BIND Administrator's Reference Manual called GSS-TSIG. Intrigued, I set out to learn more, and found that this is terribly easy to set up with BIND:

• create a DNS/<nameserver address> principal inside your realm. Note that the "nameserver address" really needs to be the name of the primary name server as specified in the SOA record of the zone; this is in contrast to pretty much every other use of Kerberos out there, where it has to be the name of the machine as specified by the PTR record of the IP address you're talking to.
• Write that principal to a file which is readable by named. I used /etc/bind/bind.keytab for this purpose. Make sure this file is owned by the UID that named runs as.
• Add a tsig-gssapi-keytab stanza to the options block in your named.conf file (or named.conf.local) on Debian. This stanza wants a string specifying the filename of your keytab file. In the above example, that becomes tkey-gssapi-keytab "/etc/bind/bind.keytab";
• In the zone block of the relevant zones, add an update-policy statement for each of the users that you want to allow to make updates; e.g., update-policy { grant exampleuser@EXAMPLE.COM zonesub any; }; will allow a user with principal exampleuser@EXAMPLE.COM to perform updates for this zone.
• exampleuser@EXAMPLE.COM can now use nsupdate -g to perform any GSSAPI-authenticated updates of the zone file.

There are a few more interesting features; e.g., krb5-self can be used to allow the host/machine@REALM principal to update the A record for machine, and there are ways to specify ACLs by wildcard. For more information, see the BIND administrator's reference manual, chapter 6, in the section entitled "Dynamic Update Policies".