On Sun, Aug 23, 2009 at 23:47, Craig Sanders<c...@taz.net.au> wrote: > On Sun, Aug 23, 2009 at 01:56:18PM +0200, Ond??ej Surý wrote: >> > a working nameserver is a core, essential component of a functioning >> > network. while named is down, *everything* on the network that uses that >> > nameserver ceases to function correctly. >> >> That's why you should never have only one "nameserver 127.0.0.1" in >> your /etc/resolv.conf. Configure one or two more remote nameservers >> and you're done. > > 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. > >> It's not critical severity - normal or wishlist would be more >> appropriate. > > it is critical. it breaks functionality for the entire local network. > >> While I agree that it's not very convenient to have bind9 stopped for >> longer time periods, there are other ways how to prevent this kind of > > 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). > > >> outage. And it's entirely different from f.e. quagga, where restart >> could mean loss of connectivity at all. Which clearly doesn't happen >> with bind - you just loose ability to resolv DNS, when you have only >> one nameserver configured. > > actually, there are multiple nameservers on the network. it doesn't help > as much as you might think. most, if not all, client resolver libraries > try nameservers in series, not in parallel. they don't try the second > or third resolver until the first times out. for some services, the DNS > timeout is longer than the connection or authentication timeout. > > clearly you have no experience of dozens or hundreds of users
and clearly you know nothing about me and you are just making angry comment. please refrain yourself of doing so next time. > whinging at you saying "the internet isn't working" or "the > file-server/intranet/web site/etc is dead" because the first nameserver > in their dhcp-assigned resolv list is down and the NEXT nameserver isn't > queried until the first times out. current timeout in resolv.conf is set to 5 seconds, either set this to lower value (if you can control the hosts), or don't upgrade the server while many users are using it (that's why we do usually do upgrades at night hours), or run some H-A solution like heartbeat or ucarp. > even if, for example, their browser has the intranet's IP cached, the > users still can't to the intranet because the login scripts can't find > the ldap server. > > DNS is not just a convenience, it's a fundamental service that > everything else on the network depends on. Yes, and that's the reason why you should not just run apt-get update && apt-get upgrade, but prepare for DNS service upgrade, if you need to keep it running all the time. While I don't exactly share LaMont's reasoning on this bug (LaMont: even if you do upgrade daemons separately, underlying libraries will change anyway while the daemon is running, so you need another restart anyway when libraries change), I do agree that it's much safer just to stop the deamon, install new version of bind9 and library dependencies, and after that to run it again. Ondrej -- Ondřej Surý <ond...@sury.org> http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
