forwarding options?

[Kevin Darcy]

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