On Mon, Aug 24, 2009 at 07:47:59AM +1000, Craig Sanders wrote: > i'm talking about a network being disrupted, not a single host. > the hosts DON'T have 127.0.0.1 in resolv.conf, they have the namesever.
I've gone back as far as 9.2.4, and haven't found anywhere that the bind9 package actually kept itself from stoping bind9 during the upgrade. I do know that bind 8 had code in the scripts to do that. > > It's not critical severity - normal or wishlist would be more > > appropriate. > it is critical. it breaks functionality for the entire local network. Generally what I've seen done is a separate IP for the resolver, and during a scheduled upgrade, that IP is migrated to another host, specifically to avoid any disruption. > it's not a matter of convenience. it's a matter of temporarily breaking > everything on the network that depends on DNS (which is pretty much > every network service or connection). Everything on the network that depends on this host for DNS. Migrating the service to another host for the duration of the upgrade, or doing micro upgrades is certainly an option. > the bind9 package has worked reliably for many years with a restart > after upgrade rather than stop-early, start-late approach. there is no > reason for the current change in behaviour. it just maximises downtime. Versions? lamont -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
