forwarding options?
Kevin Darcy
kcd at chrysler.com
Fri Feb 1 02:05:33 UTC 2008
Matus UHLAR - fantomas wrote:
> On 29.01.08 19:20, Kevin Darcy wrote:
>
>> The point is, if you're forwarding to an instance on the same server,
>> you're never going to have the "queries time out because forwarding
>> server is down" situation. Which is what you described as the problem
>> you're trying to solve.
>>
>
> the proces can still be down or not responding for whatever reason.
>
Unlikely. We've had very little downtime with rbldnsd.
> however I still don't plan rbldnsd on each machine bind runs on.
>
Why not? We run rbldnsd+BIND on all 4 of our incoming mail gateways.
It's a small footprint, low-maintenance solution.
>> As for your "cache farm" idea, it's hard to evaluate that without
>> understanding what you mean by "mirroring". Is your rbldns server
>> *authoritative* for the zones in question? If so, is it a *published*
>> nameserver for the zones in question? If it's a published nameserver,
>> then probably you should just define "stub" zones and let the RTT
>> mechanism do its thing. If it's authoritative but not published
>> ("stealth slave"), rather than building a "cache farm", why don't you
>> just "mirror" the zones on another rbldns server, and then put some sort
>> of software/hardware load-balancer in front of the two?
>>
>
> rbldnsd is authoritative from its principle - it does not receive
> informations using the DNS protocol. The zones are usually transfered via
> rsync, the "mirroring" was meant as it's used in FTP.
>
> I can't put those rbldnsd's behind balancer,
Why not?
> but even if I did, I first want
> to query my local rbldns server, then any others (public).
>
Hmmm... okay. Now you're introducing some distinction between "local"
rbldns and "public" rbldns that I don't quite understand (obviously by
"local" you don't mean "running on the same box as BIND", since you
ruled out that option above, so what does "local" really mean?)
> And don't wait too long for querying public servers. Last time I was
> sniffing the DNS comunication (to find out whan my rbldns crashed), the
> query intervals were over 6 (9?) seconds long, which is imho too much, 1-3
> seconds is just enough.
>
>
>> I don't see why you mention looping. Why would there be looping if the
>> resolution path terminates in an authoritative server for the zone in
>> question?
>>
>
> Because that is a different problem than the first one. Our "cache farm"
> means multiple recursive BIND servers on one network (behind load balancer).
> If one of them receives a request, I don't mind if it asks each other before
> it starts querying public servers (the access to local network is faster
> with more bandwidth available than access to most of the intenet).
>
> But if recursive requests would be send, caches caches would keep asking
> each other until the timeout. So we have multiple caches that are unable to
> cooperate with each other.
>
That's an intriguing idea, a mechanism to have a farm of iterative
resolvers "opportunistically" and non-recursively query each other in
parallel with their normal iterative-resolution process. Perhaps you
should suggest that to ISC.
- Kevin
More information about the bind-users
mailing list