Need help on delegation to subdomain/external servers
Kevin Darcy
kcd at chrysler.com
Thu Sep 17 16:27:27 UTC 2009
RUOFF LARS wrote:
>
>
>
>> [mailto:bind-users-bounces at 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
More information about the bind-users
mailing list