You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 ;)
The text was updated successfully, but these errors were encountered:
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.
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: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 ;)
The text was updated successfully, but these errors were encountered: