Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
--On Friday, March 22, 2013 2:54 PM -0400 Dan Ritter <dsr at randomstring.org> wrote: > Usually with a 30 second timeout. I assumed (possibly > incorrectly) that that was what he wanted to avoid. First lookup has a lifetime of 3-5 seconds. That's how long the resolver waits for a response whether or not a response is actually returned. Each successive attempt increases the lifetime by 50-100% with a maximum lifetime of 30 seconds. Given the example of a hot/hot pair and one node dies, the worst you can expect is about 6-10 seconds assuming that the remaining node isn't overwhelmed. These values are configurable for most sane resolvers so you can set them to smaller values. This is not recommended for general use as the lifetimes will end up being shorter than actual lookup turnarounds. The net effect is that performing lookups will take longer as the early requests "die" and are ignored by the resolver. This is not as much of an issue on private networks where the clients and cache servers are on the same network segment. > I'm not sure what the benefit is of a load balancer here... Say you have 500 clients and 3 name servers. Do you want all 500 hitting only the first server? Of course not. You want to balance the load across all 3 name servers. Google does this with load balancers in front of their public name servers. I would do it by shuffling my /etc/resolv.conf entries. > Anyway. Do you have any criticism of putting a local caching > resolver on each mail server? That's what I do. Nope. That's the most sensible course. I'd also list each node's immediate neighbors in their resolv.conf files in case a cache process crashes. -- Rich P.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |