Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] cluster DNS servers



--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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org