forwarding options?
Matus UHLAR - fantomas
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?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Kevin Darcy
- Kevin
Matus UHLAR - fantomas
> 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, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Kevin Darcy
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
> 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.
however I still don't plan rbldnsd on each machine bind runs on.
> 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, but even if I did, I first want
to query my local rbldns server, then any others (public).
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.
> If these "mirrored" zones aren't being served authoritatively, then I
> have no clue what you're trying to describe.
I was trying to describe two different problems (well, one problem and one
idea) where both could benefit of the maximum forwarding timeout option and
latter one would need option for disabling recursive requests
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.
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.
>>
>
> the proces can still be down or not responding for whatever reason.
>
> however I still don't plan rbldnsd on each machine bind runs on.
>
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,
> but even if I did, I first want
> to query my local rbldns server, then any others (public).
>
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.
>
resolvers "opportunistically" and non-recursively query each other in
parallel with their normal iterative-resolution process. Perhaps you
should suggest that to ISC.
- Kevin
Matus UHLAR - fantomas
I'll consider the rest, but until then:
> Matus UHLAR - fantomas wrote:
> > I can't put those rbldnsd's behind balancer,
> > but even if I did, I first want
> > to query my local rbldns server, then any others (public).
On 31.01.08 21:05, Kevin Darcy wrote:
> 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?)
I think a piece of configurastion explains it:
zone "blah" {
forward first;
forwarders { IP; };
}:
BIND first forwards request to the IP, and when response doesn't come until
timeout, it continues resolving the usual way. I want to control the
timeout. It doesn't mean if the IP is on local machine, local network or
wherever. Shit may happen and I'd like to avoid timeouts when the response
from the IP doesn't come.
> > 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.
I first wanted to see people's opinions here. Maybe there's a problem I
don't see which makes the idea nice but impossible or dangerous.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759