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.

If DNSSEC validation is not enabled in NIOS, and if NIOS is configured to forward to another DNS server (e.g. NIOS caching/recursive layer) then NIOS sends DNS queries to the caching box with DNSSEC “CD” (Check Disabled) flag bit set to “1”, and the caching server, irrespective of the local DNSSEC validation setting, will not perform any validation locally and provides the response to the “forwarding DNS server”, and the same response is sent back to the client. i.e. if you have full DNSSEC validation enabled on the external caching server but the Internal NIOS server does not have DNSSEC enabled then the external caching server will NOT perform DNSSEC validation for that query.

If you enable DNSSEC and have Trust Anchors configured on the internal DNS NIOS box, then the NIOS box will do the DNSSEC validation by forwarding the DNS and DNSKEY queries to the external caching layer to get the answers to.

If you enabled DNSSEC and have NO Trust Anchors configured, then the internal DNS NIOS box will add CD (Check Disabled) flag bit set to “0” and it will mean that it is telling the external caching server to do the DNSSEC validation on its behalf.

When enabling the “Add” and “Copy” options under DNS Properties > Forwarding, we see the following notices/warnings

The "Copy client IP, MAC addresses, and DNS View name to outgoing recursive queries" EDNS0 option will not function in the following scenarios even when you have enabled it: 
1. When you select the "Disable EDNS0" option. (Grid Properties > General > Advanced > "Disable EDNS0" (by default this option is disabled - thus EDNS0 is enabled by default)
2. When recursion is not enabled on the member.
3. The list of Grid or Member DNS forwarders is empty. When DFP is enabled on the node: DFP will re-write required statements to forwarder section of named-config. 

Do you still want to proceed? Do you want to continue?

The "Add client IP, MAC addresses, and DNS View name to outgoing recursive queries" EDNS0 option will not function in the following scenarios even when you have enabled it: 
1. When you select the "Disable EDNS0" option.(Grid Properties > General > Advanced > "Disable EDNS0" (by default this option is disabled - thus EDNS0 is enabled by default)
2. When recursion is not enabled on the member.
3. The list of Grid or Member DNS forwarders is empty. When DFP is enabled on the node: DFP will re-write required statements to forwarder section of named-config. 

Do you still want to proceed? Do you want to continue?

If DFP fails and Global Forwarders are NOT configured, root hints will be used and NIOS will not add source IP data to the queries.

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)

In the scenario below, the key is to ensure that the first layer has “Add” enabled and that the second and third layer have “Copy” enabled. If we assume that all clients query layer 1, we are good. We include “Add” in the second and third layers to allow for clients querying these layers directly.