Need help on delegation to subdomain/external servers

[Ben Croswell]

I have done some testing of the RTT forwarding and found that as long as
only one, or the other of the two "nameservers" that you forward to is
active at any given time the switch over is actually very quick.
The exception being the first query when the currently active forwarder dies
and the second comes up.  The reason being that the first query has to wait
for a timeout cycle before trying the second forwarder and readjusting the
RTT values for both.

So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as long as
only one will answer queries at a given time with their own "right" answer
it should failover fairly quickly.  If both answer then you will be at the
mercy of the RTT as to which answer you will get.

-- 
-Ben Croswell

On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy <kcd at chrysler.com> wrote:

> 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
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090917/f4c281e7/attachment.html>