]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
Update description of forwarding behavior in ARM
authorSuzanne Goldlust <sgoldlust@isc.org>
Thu, 23 Jul 2020 13:05:43 +0000 (13:05 +0000)
committerMichał Kępień <michal@isc.org>
Tue, 4 Aug 2020 19:53:23 +0000 (21:53 +0200)
(cherry picked from commit 30e126ad02c703e51e6df58ec1e84bdb72884426)

doc/arm/Bv9ARM-book.xml

index 5ea7b9ff4605134e687d7c86b9eb6942c0b4f29e..1da056516e43dbc7f22bdeb6b9388e668ab06486 100644 (file)
          </para>
 
          <para>
-           There may be one or more forwarders,
-           and they are queried in turn until the list is exhausted or an
-           answer
-           is found. Forwarders are typically used when it is undesirable
-           for all the servers at a given site to interact directly with the
-           rest of
-           the Internet's servers. A typical scenario involves
-           internal <acronym>DNS</acronym> servers and an
-           Internet firewall. Servers unable
-           to pass packets through the firewall forward their requests to the server
-           that can, and that server queries the Internet <acronym>DNS</acronym> servers
-           on the internal servers' behalf.
+           Forwarders are typically used when an administrator does not
+           wish for all the servers at a given site to interact
+           directly with the rest of the Internet. For example, a
+           common scenario is when multiple internal DNS servers are
+           behind an Internet firewall. Servers behind the firewall
+           forward their requests to the server with external access,
+           which queries Internet DNS servers on the internal servers'
+           behalf.
+         </para>
+
+         <para>
+           Another scenario (largely now superseded by Response Policy
+           Zones) is to send queries first to a custom server for RBL
+           processing before forwarding them to the wider Internet.
+         </para>
+
+         <para>
+           There may be one or more forwarders in a given setup. The
+           order in which the forwarders are listed in
+           <filename>named.conf</filename> does not determine the
+           sequence in which they are queried; rather,
+           <command>named</command> uses the response times from
+           previous queries to select the server that is likely to
+           respond the most quickly. A server that has not yet been
+           queried is given an initial small random response time to
+           ensure that it is tried at least once. Dynamic adjustment of
+           the recorded response times ensures that all forwarders are
+           queried, even those with slower response times.  This
+           permits changes in behavior based on server responsiveness.
          </para>
        </section>