forwarding options?

[Kevin Darcy]

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.

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?

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?

If these "mirrored" zones aren't being served authoritatively, then I 
have no clue what you're trying to describe.

- Kevin

Matus UHLAR - fantomas wrote:
> On 25.01.08 13:45, Kevin Darcy wrote:
>   
>> Why not run rbldnsd on the same box, on an off-port? That's what we do.
>>     
>
> That is not related to any of subjects in my question.
>
> - the forwarding is the same whether it's 127.0.0.1 or any other IP.
> - rbldns can be reconfigured (which still requires restart thus downtime,
>   iirc)
> - forwarding between farm of caches is not related to rbldns
>
>   
>> Matus UHLAR - fantomas wrote:
>>     
>>> Is it possible to tune forwarding options a bit? I'm subscribed  in this
>>> list just for a while, maybe this was discussed already, but I haven't find
>>> any record about that (links, hints welcome)
>>>
>>> I have one local rbldns server whicvh mirrors some DNS zones and I have
>>> configured BIND to forward requests for the zones to that server first.
>>> However when the server crashes or is rebooted, forwarding slows responses
>>> down too much. I would like to have an option here to set maximum timeout when forwarding
>>> to server, e.g. 3 seconds, which should be enough for deciding that the
>>> server is not alive.
>>>
>>> Another option that comes to my mind is to working with farm of DNS caches.
>>> Forwarding requests to them first could spare them from sending too many
>>> requests to the world and imho even speed up DNS resolving.
>>> That requires ability to send requests with RD bit set off not to create any
>>> loop. And also it would require the feature above not to slow down if one of
>>> caches is down.
>>>
>>> Combination of those two above would be also nice. That would require
>>> two-level forwarding - local rbldns mirror(s) first, neighbour caches after,
>>> and standard resolving then. 
>>>
>>> Any opinions? Should I just post enhancement requests?
>>>       
>
>