RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
BTW, at the moment I am experimenting a solution usign a forward zone:
zone "dummy.ts" IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses: try
one forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you forward,
you're turning named *into* a stub resolver with a cache, at least for
part of the namespace. If you forward "globally" (i.e. in "options"),
and have some authoritative zones and/or stub zones with "forwarders {
}" defined, then those are just selective "overrides" of your
stub-resolver+cache function. And if you have "forward first" anywhere,
then you're just giving named a second chance to resolve names
iteratively, in case the initial stub-resolver+cache approach fails
(because the forwarders aren't available/reachable).
Seems like extreme overkill to use a big heavyweight process like named,
to perform a simple stub-resolver function that can otherwise be
accomplished with a few library routines, doesn't it? Well it *should*
seem like overkill, because it's usually the wrong tool for the job.
Forwarding is generally to be avoided, unless you need to deal with a
limited-connectivity situation (e.g. trying to resolve Internet names to
internal clients through a firewalled environment) or, in certain select
cases, to forward to a richly-populated central cache, with ample
capacity, over fast internal links, in order to speed up the average
name resolution time for a local set of clients.
What delay do I have to expect when only the second server (192.168.2.3)
is active?
I'm not sure, I'd have to look through the code. I don't believe this
delay is configurable, by the way.
What search policy is applied by default? (round-robin vs sequential?)
Can I modify it?
Obviously I would prefer a policy where we always forward to the last
active, unless we time out; Then try the alternate.
Will check that out.
I believe that forwarder-selection uses the same algorithm as
NS-selection, i.e. it's based on the historical RTT data. So it might
not switch over as fast as you'd like.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
