<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>When I was transferred into our corporate IT Networks group, I inherited a DNS architecture based on forwarding DNS queries to regional name servers.  The regional name servers had access to the Internet and were able to provide name and address resolution for both Intranet and Internet queries.</div><div><br></div><div>The designers of the DNS architecture carefully configured the forwarders statement on each name server so that the name server for the region was listed first.  It was followed by the other regional name servers ordered by distance from the local name server.</div><div><br></div><div>Had this been implemented under BIND 8, it would have worked as the designers had expected.  Unfortunately, it was implemented under BIND 9.3.  The list of name servers in the forwarders statement was no longer treated as a sequential list as it had been in BIND 8.  Under BIND 9.3 and later releases, the selection of name server from the forwarders list is performed the same way as the selection of name server for a DNS zone:  its round-robin with a preference given to the name server with the smallest RTT.</div><div><br></div><div>Another item that the designers didn't anticipate was how RTT is calculated.  It is not based on the RTT to the forwarder but on the time that it takes for the forwarder to return a result.  Given the physical locations of the regional name servers, the calculated RTT is roughly identical even at sites where there is a local name server co-located with the regional name server.  In our particular environment, the "primary" forwarder changes approximately every 20-30 seconds.</div><div><br></div><div>Given this behavior, I'm not sure what advantage there is in having "online" and "offline" name servers.  I would opt for having all name servers "online" and let BIND select the more desirable name server.</div><div><br></div><br><div><div>On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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.<br>
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.<br>
<br>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.<br>
<br>-- <br>-Ben Croswell<br><br><div class="gmail_quote">On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com">kcd@chrysler.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
RUOFF LARS wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
 <br>
  <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[mailto:<a href="mailto:bind-users-bounces@lists.isc.org" target="_blank">bind-users-bounces@lists.isc.org</a>] On Behalf Of Kevin Darcy<br>
    <br>
</blockquote>
<br></div><div class="im">
BTW, at the moment I am experimenting a solution usign a forward zone:<br>
zone "dummy.ts" IN {<br>
        type forward;<br>
        forward only;<br>
        forwarders { 172.25.32.171; 192.168.2.3; };<br>
};<br>
<br>
It seems to work.<br>
I guess that the requests are not sent simultaneously though?<br>
  <br>
</div></blockquote>
Correct, it's similar to the algorithm that a stub resolver uses: try one forwarder, if it times out, try another, and so on.<br>
<br>
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).<br>

<br>
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.<div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What delay do I have to expect when only the second server (192.168.2.3)<br>
is active?<br>
  <br>
</blockquote></div>
I'm not sure, I'd have to look through the code. I don't believe this delay is configurable, by the way.<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What search policy is applied by default? (round-robin vs sequential?)<br>
Can I modify it?<br>
Obviously I would prefer a policy where we always forward to the last<br>
active, unless we time out; Then try the alternate.<br>
Will check that out.<br>
<br>
  <br>
</blockquote></div>
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.<br><font color="#888888">
<br>
- Kevin</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br><br>
_______________________________________________<br>bind-users mailing list<br><a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>https://lists.isc.org/mailman/listinfo/bind-users</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica Neue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica Neue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Merton Campbell Crockett</div><div><a href="mailto:m.c.crockett@roadrunner.com">m.c.crockett@roadrunner.com</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></span>
</div>
<br></body></html>