Hello,
I have defined a forward zone clause with two options "forward-addr:".
Contrary to what I expected,
the second definition _also_ receives queries
(although the first is reachable and in perfect working state).
I couldn't identify a pattern yet.
And since I'm completely unfamilar with unbound source code, and not
realy much more familar with C in general, I hoped anybody else can shed
some light on the order of evaluation in such a configuration.
Thanks in advance,
-harry
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.
-- Ralph
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?
Is there any way to influence the round-robin behaviour for a forward
zone clause (besides getting to source code)?
My intention is to have ai failover forwardern, not a load-baöancing.
For multi-A-records, bind has a static override and I think I remember
that I read something similar for unbound too (I'm new to unbound and
broke my glasses – not much reading for today 
– so I'm not trying to
verify utilizing the man page 
Thanks,
-harry
Hi Harry,
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.
-- Ralph
Bezüglich Ralph Dolmans's Nachricht vom 10.01.2018 11:28 (localtime):
Hi Harry,
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
Hello,
is this also true for master: (auth-zone clause) and/or stub-addr: (stub-zone clause)?
I mean, is there any way to define the prefered master in case of auth-zone clause, and define a second master as fallback in case there was no answer within a defined timeout?
If someone has already tried out/ knows the code I'd highly appreciate any hints.
Thanks,
-harry
Hi Harry,
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.Hello,
is this also true for master: (auth-zone clause) and/or stub-addr:
(stub-zone clause)?I mean, is there any way to define the prefered master in case of
auth-zone clause, and define a second master as fallback in case there
was no answer within a defined timeout?If someone has already tried out/ knows the code I'd highly appreciate
any hints.
It tries them in the order you specified. For auth-zone.
If there are notifies. And the notify is from a master-ip, then that
master that sent the notify also gets tried first. If that fails the
list is started from the beginning, in order. And this would then try
that master again, in the list, another time.
For stub-addr it is what Ralph said, there is also an experimental
feature where you can influence server selection for them. You can set
low-rtt and low-rtt-permil: 900 to make unbound select stub-addr and
forward-addr and internet servers from delegations that have low ping
times for 90% of the time.
Best regards, Wouter