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
