In general, if you tell a DNS server to forward all queries to another DNS server (e.g. local DNS server forwards to 1.1.1.1) then you should tick “User Forwarders Only”. (Obviously, you will want more than just one IP. 1.1.1.1 & 1.0.0.1 is much more resilient than just 1.1.1.1). This is because by the time the recursive DNS server falls back to top-down recursion, a stub resolver (client) has already waited for quite a while. If the recursion takes some time, the stub resolver might well give up. Also, the more forwarders you have defined, the more forwarders the DNS server has to check before it can fall back to recursion. Fall back to recursion time also depends on BIND version but the more modern BIND uses RTT which effects overall time, and finally there are mechanics at play as well for EDNS0 backoff where it will try increasing Timeouts (something like 1.6s, 3.2s, 6.4s 9s until it hits the default max which is something like 30s total)

How the round trip time(RTT) algorithm works.

While using more than one Forwarders, Infoblox just like BIND Name Servers uses a metric called Round Trip Time, or RTT, to choose among the Configured Servers to Forward to. Roundtrip time is a measurement of how long a remote Name Server takes to respond to Queries.

Each time a BIND Name Server sends a query to a remote server, it starts an internal stopwatch. When it receives a response, it stops the stopwatch and makes a note of how long that remote Server took to respond. When the Name Server must choose which of a group of Authoritative Name Servers / Forwarders to query, it simply chooses the one with the lowest Roundtrip time.

Before a BIND Name Server has queried a nameserver, it gives it a random Roundtrip time value lower than any real-world value. This ensures that the BIND Name Server queries all nameservers authoritative for a given zone in a random order before playing favorites.

On the whole, this simple but elegant algorithm allows BIND Name Server to “lock on” to the closest nameservers quickly and without the overhead of an out-of-band mechanism to measure performance.

To give you a clearer picture, here’s how it works

Initially, each forwarder’s RTT is seeded with a random, low value.

When the recursive name server needs to forward a query, it chooses the forwarder with the lowest RTT.

When it sends a query to the chosen forwarder, it starts an internal timer. When it receives a response, it stops the timer.

If all the recursive name server has is the seeded value for the chosen forwarder, it replaces that value with the value from the timer.

If the recursive name server has a real RTT based on previous responses, it updates the RTT based on the timer’s value: new RTT = (.7 * old RTT) + (.3 *timer).

Forwarders that aren’t selected have their RTT values “decayed” by multiplying them by .98. This enables all the configured Forwarders to eventually get their turn.

In short, No. The order in which the forwarders are listed has no bearing on the order in which they are used.

Notes on using “Add” and “Copy” options for NIOS Forwarding with DFP.

• Source IP (Laptop) = 192.168.99.73 (Queries 192.168.11.211)
• First NIOS Member = 192.168.11.211 (Forward only to 192.168.11.212)
• Second NIOS Member = 192.168.11.212 (Forward only to 192.168.11.215)
• Third NIOS Member = 192.168.11.215 (DFP enabled and no forwarders configured locally)