On 2010-09-29, at 13:07, Brian Smith wrote: > I'm looking for an installation that will use multiple resolvers. What I > would like to do is to use 1 server that will be the shared cache for all of > the resolvers to share. Theoretically this will reduce the amount of traffic > going out of the network as well as reduce latency. > > I've looked at the usual suspects, bind, djb and unbound, for this and have > been left wanting. Any suggests are very welcome and I thank the group for > accepting my topic for discussion.
Resolvers are sensitive beasts; when the resolver goes down the helpdesk phone rings. A client with two resolver addresses supplied during IPCP or DHCP tends not to add much practical redundancy since failing over from one to the other involves a timeout. Availability is hence most visible on the servers that end users talk to. I have heard talk of the following: - deploy multiple servers providing user-facing resolver service on a single address, e.g. using anycast (e.g. see RFC 4786, <http://www.usenix.org/events/usenix04/tech/sigs/full_papers/abley/abley.pdf>, <http://www.usenix.org/publications/login/2008-02/openpdfs/abley.pd>f, <http://nanog.org/meetings/nanog34/presentations/abley.nameservers.pdf>) - deploy one or more servers providing intermediate resolver service (the shared cache you mention) - configure the user-facing resolvers to use the intermediate resolvers (e.g. use "forward first" and "forwarders" phrases in named.conf, or maybe a forward-zone "." phrase with unbound, YMMV, read the manual, this is from memory). Anycasting the user-facing resolvers means you have the ability to take them down and patch them without users seeing any/much downtime. Your helpdesk will thank you. The use of non-user-facing intermediate resolvers means you can restrict the clients able to use it to just the user-facing resolvers, perhaps meaning that it is less vulnerable to harmful effects caused by software defects (since the client population is run by you), and hence perhaps you need to patch/reboot/flush it less often. Maybe this is wishful thinking. You might want to think about whether it's wise to use a single intermediate resolver, or whether you should experiment with using multiple (use anycast again, or verify that the user-facing resolvers will fail over nicely between multiple unicast servers). A single point of failure will make you lose sleep at some point. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
