Comment 3 for bug 1086775

With as many users as we have, a common misconfiguration can lead to a number of reports. I'd have expected dozens of reports or more by now if this were a systemic upgrade problem. Also note that one of the reports you linked to has root group ownership too, which is inconsistent with a single root cause.

I've looked at the ways the bind9 maintainer scripts call chmod, and don't see how a group write permission could get lost:

$ grep chmod /var/lib/dpkg/info/*bind*
/var/lib/dpkg/info/bind9.postinst: chmod 775 /var/lib/bind
/var/lib/dpkg/info/bind9.postinst: chmod g+s /etc/bind
/var/lib/dpkg/info/bind9.postinst: chmod g+r /etc/bind/rndc.key /etc/bind/named.conf* || true
/var/lib/dpkg/info/bind9.postinst: chmod g+rwx /var/run/named /var/cache/bind

I've checked the maintainer scripts this way across Hardy, Lucid and Precise. It looks to me that the existing postinst intentionally avoids doing the chmod except in a particular circumstance which I presume is for upgrading from a specific previous version (presumably prior to Hardy). I'd like to understand the root cause before I'm comfortable pushing to change this, and there is a trivial workaround for those affected.

So steps to reproduce the problem would really help!