If you've upgraded a Debian etch system running DebPkg:bind9 to lenny, these are some of the issues you're likely to face:

 * bind9 no longer allows recursive queries by default; you may need to add `allow-query { any; };` to `named.conf` to get the previous behavior.
 * `/etc/default/bind9` needs to contain `OPTIONS="-u bind"` but the etch file will not be altered during the upgrade.  You must edit it by hand.  This in turn will cause `named` to run as the user account `bind`, so you may also have to change the ownership or permissions of cached zone files in `/etc/bind` if you are a slave for any domains.  (It may be best to set up a subdirectory of `/etc/bind/` and give user account `bind` ownership and write permission, and put all your slave caches there.)
 * The upgrade will probably not be able to stop the `named` process due to changes in how rndc is configured.  You may have to kill the old `named` process manually (assuming you don't just wait for a reboot).
 * If you had a logging configuration like this in `named.conf`:
 {{{
logging {
  category cname { null; };
};
 }}}
 then the new `named` will fail to start.  This and any other obsolete logging directives must be commented out.
 * In order for the boot script (`/etc/init.d/bind9`) to be able to stop/reload/etc. the running `named` process, it must be able to signal it using something called "rndc".  This requires the presence of two files under `/etc/bind`: `rndc.key` and `rndc.conf`.  The key file is present after the upgrade, but the `rndc.conf` file may be missing.  If it's missing, create it by hand with the following content:
 {{{
options {
  default-server localhost;
  default-key "rndc-key";
};
include "/etc/bind/rndc.key";
 }}}
 Ideally, you should do this before restarting `named`, so that it will use the correct rndc mechanism and key.  (''This issue may actually have arisen during a post-etch security patch, so you may already have fixed this one.'')