On 2025-12-20 9:39:20, Otto wrote: >> As mentioned before unbound runs chrooted to /var/unbound so after chroot is >> in \ >> effect logs and such will say /etc/unbound.conf but in really is \ >> /var/unbound/etc/unbound.conf. Also of note unbound changes userid to >> _unbound so \ >> permissions must be for that user. > > According to the debug log, root starts the daemon reading \ > /var/unbound/etc/unbound.conf, then enters /etc in the chroot and drops > *user* \ > privileges to run as _unbound. After that, in the log any reference to \ > /etc/unbound.conf truly means /etc in the chroot. The log could be nicer:
Unbound may startup as root but when doing a "reload" the service is already running as _unbound and can't go back to root (do a restart for that), so a reload needs to be able to re-read files as the _unbound user. >> Note: the _unbound user has read-only access (good security). > > No, if you set the file owner to _unbound, it has write access. > >> -rw-r----- 1 _unbound wheel 2957 Dec 12 10:46 local.unbound Does unbound need to make changes to "local.unbound"? If not keep it read-only for security (so if the service is compromised the intruder can't easily start reconfiguring unbound to further the intrusion). > /var/unbound/log: > total 4176 > drwxr-xr-x 2 root _unbound 512B May 11 2023 ./ > drwxr-xr-x 5 root wheel 512B Oct 12 20:32 ../ > -rw-rw---- 1 root _unbound 2.0M Dec 20 09:35 current > > I hope it is enough. > > I should not be doing it, however. I expect sane defaults instead. OpenBSD uses sane defaults for what it provides. For logging they use syslog (and syslog can be configured to put everything unbound in a separate log file). But you can let unbound do its' own logs as you are doing, but then you are now the one setting it all up. I haven't looked at how/if unbound does log rotation, if it does then you'll likely need to have /var/unbound/log group writeable by _unbound (this is why my earlier reply modelled after the db directory) so it can create the next log file. >> Since I have a second unbound running named unbound2 in /etc/rc.d I also had >> to \ >> create: $ cat /etc/login.conf.d/unbound2 >> unbound2:\ >> > tc=unbound: >> to pick-up the same settings for both instances. > > A single daemon with libevent seems beafy enough nowadays. I would agree but I need two instances for function not performance. My primary unbound forwards everything, mostly to public dns resolvers. But some sub-domains I need to do recursive resolution directly (ex: RBLs). So I run a second unbound instance for that purpose and the primary unbound forwards those sub-domains to the second unbound instance for resolution. "forward-first: yes" says it'll fall back to normal recursive resolution if forwarding fails. No it doesn't it'll fall back to the next best matching forwarder: (if defined). All the forwarders would have to fail and all would have to have "forward-first: yes" before normal recursive resolution would occur. Would be nice if forwarders allowed exceptions like some of the other features in unbound have. If I could do this in one instance without a nightmarish config I would. > According to the unbound recommendations, both rcv and snd should be 4m. > I would love to know the difference between these: True but as the other thread points out OpenBSD doesn't do buffers here. On 2025-10-12 21:19:16, Alexander wrote: > Just setting it to 1 MB like in your diff fixes the warning and > does not confuse people. He underestimated us, lol. We got to get "buffer" out of our heads here. On 2025-12-20 11:25:27, Stuart wrote: >> For good(?) measure I recently added "num-threads: 4" (I settled on four >> after monitoring, >> but having just 1 thread has always worked too) > > It can help with distributing load for high query volumes but I think > you're not going to get really good distribution between the instances > on OpenBSD this way. Suspect you'll probably get better qps handling > by front ending with dnsdist and distributing to separate resolver > instances bound to different ports, but this is overkill for anything > other than *busy*. I'm just one individual with small army of gadgets and IoT rebels, so not *busy*. I was just going for some improvement but still keep configuration simple. My monitoring definitely shows how unbalanced the queries are distributed and I do remember reading somewhere this would happen. It's ok I'm not going big, was just trying to offset for not using a large openfiles (I'm tinkering). My preference is not to change OpenBSD's settings (and keep it small if I do). A few years ago when I had to setup unbound on a windows server, all queries would only go to the first thread and everything else got zero queries. So set it back to one thread, it was still a great caching resolver machine. > As there's no buffer for UDP here there's no need to set this above > max size of a single packet size, I just used 1M because that's what > upstream did before the commit that changed it to 4M. You and Alexander explained it well in the other thread, thank you! > don't skip over the first paragraph. "Most users will probably not have > a need to tune and optimise their Unbound installation, but it could be > useful for large resolver installations." a server for e.g. a couple of > hundred workstations is not large in DNS resolver terms. Very much true. I'm doing it hopefully so I can learn and understand more (my tinkering). I have also stopped using nsd and moved my zones to unbound's auth-zones. Didn't even need to edit the zone files (although I did some edits). These are my internal zones, not internet facing. In my recursive instance I added a bunch of local-zone: always_nxdomain for RBL lookups to private addresses (ex: rfc1918). Also added rfc8806 auth-zone just for learning. Yes it's overkill for my environment.
