![]() |
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 Fri, Mar 22, 2013 at 09:50:16AM -0700, Dave Peters wrote: > It's for mail server and could not use cache dns. I suspect there's a translation error here. Normally a mail server would want a caching resolver either on the same host or nearby, because mail servers do so many lookups. You could have a non-caching resolver, but that would be silly. (Limited exceptions apply.) And there's no particular relationship between auth dns and a mail server. So I'm going to assume -- and please, tell me if I'm wrong -- that you have a bunch of mail servers that all need reliable, quick resolver service. The most resilient method would be to equip each of the mail server hosts with its own local resolver. This is inefficient in the sense that the cache won't be shared between machines, but for any reasonable number -- up to a hundred, let's say -- the increased traffic really won't make much difference. It's very small compared to the bandwidth being used for mail. This is a very simple config for BIND, tinydns, or indeed any other caching DNS server. I recommend it to you. Very little can go wrong after you've set it up and tested it. The next best method would be to use a group of DNS servers that had failover for the service IP address. There's no need for loadbalancing unless you are a much, much larger operation than I suspect, so something very simple like heartbeat will do for the failover portion. -dsr-
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |