forward-addr priority or weight

[AlexeiKlimenko]

Hello!

We define several "forward-addr" for zone as shown below: forward-zone: name: "." forward-first: no forward-addr: XXX forward-addr: YYY

How does the Unbound handle with several Forward-Addr? RoundRobin, LeastConn or any another approach? Could we manage this behavior with setting priority, weights etc?

Thanks for answer in advance!

[gthess]

Hi @AlexeiKlimenko! Unbound uses its default server selection algorithm for all upstreams, including manually configured ones with forward-zone or stub-zone for example. You can read about it at https://unbound.docs.nlnetlabs.nl/en/latest/reference/history/info-timeout-server-selection.html.

We have some vague plans to make the server selection for configured zones configurable in the future but I have nothing more to share at the moment. If you have a specific configuration you would like to see please share it so that we can take it into account.

[liang-hiwin]

You can refer to the dnsproxy mode，Defines the upstreams logic mode, possible values: load_balance, parallel, fastest_addr (default:load_balance).

[shubhhq]

I want to know, if in the forwarding case shared by AlexeiKlimenko how can I achieve the following? Try forward XXX all times and only fallback to YYY when XXX fails? My understanding is that if RTT for XXX and YYY is under 400ms they are treated equally, but I either want XXX always first or want the number 400ms configurable. Is that possible today? thanks!

[gthess]

My understanding is that if RTT for XXX and YYY is under 400ms they are treated equally,

The 400ms RTT band is caclulated from the fastest server. So if the fastest server is 1000ms away, a 1300ms server is still in the fastest band and eligible to pick.

The RTT band is not configurable. Also apart from Unbound's default server selection algorithm that I shared, there is currently no other selection algorithm to choose from.

The only thing you can do but I don't know if it is of interest in your case, is to have more a specific forward-zone fallback to a less specific one. Then you could "fake" the fallback forwarder, but this only works with forwarders of different domain names, not forwarders of the same domain. Something like:

forward-zone:
    name: '.'
    ...
    forward-first: yes  # optional, it means that if this forwarder fails, Unbound will fallback to full recursion
    ...

forward-zone:
    name: 'domain.'
    ...
    forward-first: yes # it means that if this forwarder zone fails, Unbound will fallback (to the less specific zone in this case)
    ....

[gthess]

Closing this as an already answered question, not an issue.