Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Extend cachedb to add support for redis sentinel #1094

Open
flipsed opened this issue Jun 20, 2024 · 0 comments
Open

[FR] Extend cachedb to add support for redis sentinel #1094

flipsed opened this issue Jun 20, 2024 · 0 comments

Comments

@flipsed
Copy link

flipsed commented Jun 20, 2024

Current behavior

Is there a current behavior that the feature relates to?
I would like to propose an extension to the cachedb redis implementation.

If yes, would you wish the current behavior to change?
The current implementation is great, my feature request is an extension to the current implementation

Describe the desired feature

A clear and concise description of what the feature should be.
When running large clusters of unbound, most people will want to leverage redis so that the pods can have a shared cache. Based on the unbound documentation, it's the responsibility of the user to ensure that redis is available.

This backend uses synchronous communication with the Redis server based on the assumption that the communication is stable and sufficiently fast. The thread waiting for a response from the Redis server cannot handle other DNS queries. Although the backend has the ability to reconnect to the server when the connection is closed unexpectedly and there is a configurable timeout in case the server is overly slow or hangs up, these cases are assumed to be very rare. If connection close or timeout happens too often, Unbound will be effectively unusable with this backend. It’s the administrator’s responsibility to make the assumption hold.
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html

Redis now has a feature called redis sentinel which allows us to do automatic failover in the situation where we have a master and multiple replicas and the master fails. This makes redis more resilient to failures and works towards achieving High Availability.

The current unbound configuration doesn't support the redis sentinel use case. Currently, we can select the redis host with redis-server-host. This is problematic with redis sentinel because the master may change, which means the redis-server-host must also change in case of a master failure. The redis docs indicate that the master host is obtained by running this command on the sentinel:

SENTINEL get-master-addr-by-name master-name

Some popular redis clients have added the support for sentinel. Along with the official docs, this could be a starting point to see what changes are needed to support this new feature:

Potential use-case

Describe how you see this feature being useful to other Unbound users.
I'll admit, this is not for your everyday pihole + unbound homelab user (which might be the majority of unbound users, idk). This feature is targeted towards people running large unbound clusters with cachedb/redis.

Note: I used to be your neighbour, I did the SNE/OS3 MSc at UvA in science park. Hope you peeps are doing well, fijn dag ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant