[Feature Request] Blocky should start resolving DNS traffic using available upstream ASAP

[PeterDaveHello]

To prevent misunderstanding, this issue is not a duplicate of #566. #566 is addressing the blocking caused by the blocklist/allowlist, I'd like to discuss about the upstream resolver here.

When there are many upstream resolvers in the config, like this: https://github.com/PeterDaveHello/dnslow.me/blob/master/blocky-dns-proxy-config.yml, looks like blocky will take a while to start(almost a minute in my case), if there wasn't any high-availability architecture in the service, the restart usually will cause a down time.

Maybe just like #566/#636, we can allow blocky start to resolve queries once there's any working upstream?

Thanks!

[0xERR0R]

Which version of blocky do you use currently? Maybe #749 is relevant for you.

[PeterDaveHello]

@0xERR0R v0.20 the latest stable release. Will take a look at #749, thanks.

[PeterDaveHello]

@0xERR0R looks like there's still a little bit different, but maybe not important at all.

According to the document, here's the description of startVerifyUpstream

If true, blocky will fail to start unless at least one upstream server per group is reachable.

So looks like current policy is to check all the upstreams once to make sure at least one of them works, or check none of them, and then start to serve. What I'm thing about is still to check them all, but once any of upstreams is working, then start to serve, not to wait for the check completed.

[ThinkChaos]

If startVerifyUpstream is true, blocky exits directly if all of the upstreams fail.
The easiest way get the behavior you want, is to rely on whatever manages your blocky server (docker, systemd, etc.) to restart it if it fails. That way it will retry the startup checks until at least one upstream works.

To implement this behavior in blocky, we could change startVerifyUpstream to accept something like retry where it retries to startup regularly. But I'm not convinced that's a good fit for blocky.
Maybe just having a specific exit code for "startup checks failed" would be enough so that the process manager can be more intelligent about when to restart blocky.

[PeterDaveHello]

Just leave a record that it takes about minutes starting to resolve queries if there are many upstream 😅

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ThinkChaos]

Making Blocky test the resolvers in parallel could be a good improvement here.
We could also add a startStrategy option where fast would start immediately and use the bootstrap resolver (which defaults to the system resolver), and blocking would be the current behavior.

Both of those should not be too hard after #998 is merged.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[PeterDaveHello]

Oh, please keep it.

[ThinkChaos]

Finally got around to finishing my PR for this :)
See #1283