I use unbound largely out of a habit to try different things. Your mileage will vary.
Issue: Make sure unbound-anchor has its path specified in its init.d script. Think this got fixed in an update but if not, you may see it whine at you.
- I start by copying over the sample configuration file. It's a decent starting point.
- Since I'm not using this for a major DNS server (it will never serve an external request), I set threads to 2.
- Set localhost and private interfaces
- Outgoing interfaces as appropriate - especially for IPv6
- Outgoing range: 480
- Restrict ports to a smallish (~8k) range
- Largely so you know you have a safe range for other UDP services e.g. Mumble
- Be sure to add bound ipv6 addresses to /etc/network/interfaces - AnyIP only binds inbound.
- Don't forget access-control
- Outgoing/incoming tcp buffers 16
- I set most cache sizes to 32m - you'll want a lot more for more important servers, however.
- Slabs at 4 (equal to number of threads or so)
- Turn on prefetching for results and keys.
- auto-trust-anchor-file: "/var/lib/unbound/root.key"
- control-enable: no under remote-control:
Set this up so we actually query ourselves!
# Unless we're dealing with an intranet of some sort, set search to some nonsense tld. search invalid # Default timeout is 5, have had some issues with 1. options timeout:3 nameserver ::1 nameserver host.or.google.here nameserver host.or.google.here
Unbound sometimes chokes on me, if rarely, and my members then complain about not getting their notifications immediately. I wrote a watchdog script to take care of this:
#!/bin/sh run=`ps ax | grep "/usr/sbin/unbound" | grep -v grep | cut -c1-5 | paste -s -` if [ "$run" ]; then continue else /etc/init.d/unbound start fi
And for /etc/cron.d/unbound (or whatever)
3,23,43 * * * * root /root/watchdog.unbound.sh
If that's where you put your watchdog script. I'm lazy.