Multiple forward-addr: _ order of evaluation?

[Harry Schmalzbauer]

 Bezüglich Ralph Dolmans's Nachricht vom 10.01.2018 11:28 (localtime):
> Hi Harry,
>
> On 10-01-18 06:31, Harry Schmalzbauer wrote:
>>  Bezüglich Ralph Dolmans via Unbound-users's Nachricht vom 09.01.2018
>> 10:53 (localtime):
>>> Hi Harry,
>>>
>>> Unbound selects forward addresses in the same way as it selects
>>> addresses for normal delegations. That is a random selection over the
>>> list of addresses with an RTT band of 400 msec.
>> Thank you very much, Ralph.
>>
>> Unfortunately I'm not sure how to understand RTT in that context.
>> Is it "wait 400msec for an answer and take next available on it there
>> was no answer within that timeout?
>> Of is it, prepare to use new forwarder from list every 400ms, regardless
>> if there were succesfull or unsuccessfull queries?
> Unbound keeps track of the round-trip time per address and uses this
> information in the server selection. All addresses with an RTT of not
> more than 400msec above the lowest RTT are used for the selection. From
> this list of suitable addresses one is randomly picked.
>
> So, assuming that the RTT difference between your two addresses is less
> then 400msec, they are both considered for selection and one of them is
> randomly picked.
>
>> Is there any way to influence the round-robin behaviour for a forward
>> zone clause (besides getting to source code)?
> No, this is currently not possible.

Hi Ralph,

thanks a lot for the explanation!

It shouldn't be too hard to implement a workaround to achive my goal then:
The failover/fallback forwarder answers with a delay > 400ms.

So it isn't used as forwarder under normal circumstances.
If the non-delayed (primary) forwarder isn't reachable for whatever
reason, the delay is guaranteed to be bigger than the artifical 0,5s
delay of the fallback forwarder.
Does unbound then (re-)select the forwarder with 0,5s (2s<RTT>400ms) or
is it permanently excluded?

In case there's no ready to use option for dealayed answers in the
forwarder (bind/powerdns/NDS/whatever), it might be not much more effort
to extend unbound to such a fallback feature – unfortunately, both were
solutions I need to retire before I could find time to start one of it
:-( ; but if so, I'd choose unbound to start with ;-)

Thanks,

-harry