Consider sanity check and warning with some "forward first" configurations
Description
The option 'forward first' is typically used with a specific forwarder or set of forwarders, presumably usually to provide better overall service, while still allowing BIND to fall back to standard iterative recursion when/if the forwarder(s) fail.
If a forwarder is down (non-responsive) for an extended period of time the srtt will grow influencing the tiemout allowed for queries to that forwarder. The upper limit for the timeout is 9 seconds. How long this takes depends on query load, with more load driving the srtt upwards more quickly.
Because forwarders are tried in serial, this leads to a pessimal delay before attempting iterative recursion of 9 * num_forwarders, in seconds.
The default value for 'resolver-query-tiemout' is 10 seconds. In the pessimal case with one forwarder that allows only one (1) second for recursion, but it does allow recursion.
With two forwarders a 'resolver-query-timeout' of at least 19 seconds is required to guarantee that there is at least a little bit of time for iterative recursion.
An operator who chooses to use 'forward first' instead of 'forward only' is desiring the fallback to iterative recursion but may not be aware that their choice of forwarders and 'resolver-query-timeout' (especially if left at default) may not be able to guarantee that there is always time for iterative recursion.
There is currently no means of detecting this latent condition aside from manual inspection of the configuration or an extended period of non-responsiveness from the forwarders that causes resolution to fail.
Request
After parsing the config, named should have all of the information it needs to determine whether or not the combination of 'forward first', the list of forwarders, and the 'resolver-query-timeout' as such that it's guaranteed that there's always at least some time to fall back to iterative recursion. It could issue a warning if this is not the case.
Notes
This feature request was created in response to a customer issue but has not (yet) been requested by that customer.