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 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. 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. 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. craig -- craig sanders <c...@taz.net.au> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
