Support: Relay randomization

[junkurihara]

Hello,

In the documentation, the following was mentioned as caveats.

For each server, a random relay from the set is chosen when the proxy starts, and the same relay will be used until the proxy is restarted. Relay randomization and failover will be implemented in future versions.

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-DNS

I just implemented the relay randomization mentioned above (since I needed :-) ). The option of relay randomization can be enabled by making relay_randomization true in dnscrypt-proxy.toml. If this is enabled, one relay server is randomly chosen from an array of relay candidates at each query issuance.

If you are okay, please review and consider to merge this commit. Thanks a lot for this quite nice software!

[lifenjoiner]

I'm not an expert on this, but only do 1 thing in 1 commit, please.
Atomic commits: One change, one commit.

[junkurihara]

@lifenjoiner Hey, thanks for your comment. Yes, you're right. I just simply followed commits on the original master branch on my fork, and unintentionally, it was pushed to the remote repo. my commit itself is actually only one for the feature. will revert it to the commit 02461e8.

[lifenjoiner]

I mean, for example:

[black-ish]

What's the status on this? It's been quite a while.

[bertusdebruin]

Interesting feature. Thanks @junkurihara Apparently it's quiet over here. Feasible feature @jedisct1 ?

[jedisct1]

This is an interesting feature, but it has a couple implications.

What should via = ['*'] do in a route in such a situation?

Also, rtt computation doesn't really work any more, at least with the current code, with multiple routes.

This code also conflicts with ODoH relays, which is why I postponed its review. One thing at a time :)

ODoH may have introduced regressions in the way relays work, so the intent is to release a version with the ODoH set of changes first, and then look at how to add relay randomization on top of that. Order is arbitrary, but one thing at a time :)

[lsm5]

Hello @junkurihara . Just curious about the status of this feature. Would be great to have this.

[junkurihara]

Hello @lsm5 ,

Hello @junkurihara . Just curious about the status of this feature. Would be great to have this.

This PR to dnscrypt-proxy is currently pending. Also I did not implemented this feature based on ODoH yet.

Here's my forked version tracking the master branch of original dnscrypt-proxy and having several additional features like relay randomization. If you like you can use it to use relay randamization.
https://github.com/junkurihara/dnscrypt-proxy-modns

[Daasin]

Also I did not implemented this feature based on ODoH yet. @junkurihara

Hopefully you manage to 😊 thank you for the work and can't wait to try it!

[Queuecumber]

Would be great if this could be prioritized, it's the only PR on the repo right now and it's been well over a year since submission

[Daasin]

Is there an update on this by any chance?

[p060477]

no news...???... :(

[Daasin]

Hello @lsm5 ,

Hello @junkurihara . Just curious about the status of this feature. Would be great to have this.

This PR to dnscrypt-proxy is currently pending. Also I did not implemented this feature based on ODoH yet.

Here's my forked version tracking the master branch of original dnscrypt-proxy and having several additional features like relay randomization. If you like you can use it to use relay randamization. https://github.com/junkurihara/dnscrypt-proxy-modns

@junkurihara Were you able to get the ODoH-based support feature implemented in the end? 🤞🏽👀
Or do you plan to while this is pending to be merged upstream/mainline 🙏🏽

[lifenjoiner]

The current solution is not that bad, and the wiki has been updated to:

For each server, a random relay from the set is chosen when servers are ranked, and then holds for a period. The cycle period is cert_refresh_delay. Per request relay randomization is too hard to measure the route quality, that may break the lb_strategy quality.

That explains that @jedisct1 said about the rtt computation. More: goto above #1584 (comment).

In short, relay randomization is not for per request, but holds since each complete re-ranking.
You can minimize the cert_refresh_delay to 60 minutes, if you concern this very much.