Arch Linux

stefan

Member

Registered: 2013-03-22

Posts: 120

From pdnsd to unbound + valkey

Until recently, I’ve been using pdnsd as a persistently (across reboot) caching frontend to a third-party DNS server that I trust wrt. privacy. That service recently switched to require DNS over TLS, and unfortunately `pdnsd` does not support that.

unbound does support DNS over TLS, and may act as a forwarding DNS server, but additionally needs `redis` for persistent caching.

How to do this exactly is identified as “need for expansion” in the wiki, so maybe my writeup can be used to this end (although I do not consider myself sufficiently competent on this topic).

Since `redis` seems to have turned to the dark side of the force, valkey is suggested instead.

I got this working with configuration files

$ cat /etc/unbound/unbound.conf
# Cf. unbound.conf(5).  Paths relative to chroot.

server:
  trust-anchor-file: "trusted-key.key"
  tls-system-cert: yes
  module-config: "validator cachedb iterator"

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 5.9.164.112@853#dns3.digitalcourage.de

cachedb:
  backend: redis
  redis-server-path: "valkey.sock"

and

$ cat /etc/valkey/valkey.conf
# Cf. https://valkey.io/topics/valkey.conf/ for configuration,
# and https://valkey.io/topics/lru-cache/ for memory eviction.

protected-mode yes
port 0
unixsocket /etc/unbound/valkey.sock
unixsocketgroup unbound
unixsocketperm 770

maxmemory 10mb
maxmemory-policy allkeys-lru
maxmemory-samples 5

and running the services by hand:

# valkey-server /etc/valkey/valkey.conf
# unbound-checkconf && unbound -dd -v

The biggest obstacle is to make `unbound` find the unix domain socket provided by `valkey`, and I’m still unsure how to best set this up.

• Since `unbound` chroots, a socket in `/run/valkey/valkey.sock` becomes inaccessible.

• `valkey` must start first, so that `unbound` can connect to it.

• I doubt that `/etc/unbound/` (which is where `unbound` chroots to) is a good place for `valkey.sock` (which changes on every reboot).

• If `unbound` runs in a `chroot` environment, then does it make sense to have it communicate with a `valkey` that does not? Should both `chroot` to the same directory? What should that directory be, and how to set it up? Systemd?

• I wonder whether the somewhat generic instantiation of `valkey` by the provided `valkey.service` should be replaced by one dedicated to the task of DNS caching exclusively. I.e., would it be better to have a `.service` file that runs `valkey-server` specifically for `unbound`, and leave the original `valkey.service` for other uses?

• I’m unsure about how to write the systemd `.service` files to get the dependencies (i.e., startup order at boot, or what happens if one of them fails) right. Also, the current `unbound.service` seems quite elaborate (`CapabilityBoundingSet`, etc.) and I really don’t know what would be appropriate for `valkey`.

• Also, I’m not sure I like the `sysctl vm.overcommit_memory=1` that seems to be required by `valkey` (as a message insits on startup). Can this be done per-process, for `valkey` alone?

What’s your take on this?

Cheers Stefan

stefan

Member

Registered: 2013-03-22

Posts: 120

Re: From pdnsd to unbound + valkey

PS:  It was a deliberate decision to use unix domain sockets instead of TCP between `unbound` and `valkey`. Because `valkey` defaults to insecurely bind to all detwork devices, because unix domain sockets supposedly cause less overhead (although I doubt it would be really relevant here), and because that’s what unix domain sockets are there for ;-)

nl6720

The Evil Wiki Admin

Registered: 2016-07-02

Posts: 707

Re: From pdnsd to unbound + valkey

I tried this and also could not get very far. Instead of running the daemons by hand, I used the systemd units and created a drop-in for unbound.service:

[Service]
BindPaths=-/run/valkey:/etc/unbound/run/valkey

This allows using

redis-server-path: "/run/valkey/valkey.sock"

The next issue is file permissions. Neither adding unbound to the valkey group as instructed in https://wiki.archlinux.org/title/Valkey … _on_socket nor adding SupplementaryGroups=valkey to unbound.service drop-in allowed to use 770 permissions for the socket

error: failed to connect to redis server: Permission denied

I could only get it to work with

unixsocketperm 777

in /etc/valkey/valkey.conf, but that's not ideal.