Unbound does not want to run for me. I just reinstalled it on my Raspberry Pi 4 running DietPi v8.3.1 with AdGuard.
A dig request via SSH already does not work, it comes
Command not found
.
service unbound status
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/unbound.service.d
└─dietpi.conf
Active: active (running) since Sun 2022-04-10 11:37:28 CEST; 6min ago
Docs: man:unbound(8)
Process: 3370 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 3373 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Main PID: 3376 (unbound)
Tasks: 1 (limit: 4915)
CPU: 161ms
CGroup: /system.slice/unbound.service
└─3376 /usr/sbin/unbound -d -p
Apr 10 11:37:28 DietPi systemd[1]: Starting Unbound DNS server...
Apr 10 11:37:28 DietPi package-helper[1872]: /var/lib/unbound/root.key does not exist, copying from /usr/share/dns/root.key
Apr 10 11:37:28 DietPi unbound[3376]: [3376:0] info: start of service (unbound 1.13.1).
Apr 10 11:37:28 DietPi systemd[1]: Started Unbound DNS server.
This is what /etc/unbound/unbound.conf.d/dietpi.conf looks like:
# https://nlnetlabs.nl/documentation/unbound/unbound.conf/
server:
# Do not daemonize, to allow proper systemd service control and status estimation.
do-daemonize: no
# A single thread is pretty sufficient for home or small office instances.
num-threads: 1
# Logging: For the sake of privacy and performance, keep logging at a minimum!
# - Verbosity 2 and up practically contains query and reply logs.
verbosity: 0
log-queries: no
log-replies: no
# - If required, uncomment to log to a file, else logs are available via "journalctl -u unbound".
#logfile: "/var/log/unbound.log"
# Set interface to "0.0.0.0" to make Unbound listen on all network interfaces.
# Set it to "127.0.0.1" to listen on requests from the same machine only, useful in combination with Pi-hole.
interface: 127.0.0.1
# Default DNS port is "53". When used with Pi-hole, set this to e.g. "5335", since "5353" is used by mDNS already.
port: 5335
# Control IP ranges which should be able to use this Unbound instance.
# The DietPi defaults permit access from official local network IP ranges only, hence requests from www are denied.
access-control: 0.0.0.0/0 refuse
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.1/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
access-control: ::/0 refuse
access-control: ::1/128 allow
access-control: fd00::/8 allow
access-control: fe80::/10 allow
# Private IP ranges, which shall never be returned or forwarded as public DNS response.
# NB: 127.0.0.1/8 is sometimes used by adblock lists, hence DietPi by default allows those as response.
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
# Define protocols for connections to and from Unbound.
# NB: Disabling IPv6 does not disable IPv6 IP resolving, which depends on the clients request.
do-udp: yes
do-tcp: yes
do-ip4: yes
do-ip6: yes
# DNS root server information file. Updated monthly via cron job: /etc/cron.monthly/dietpi-unbound
root-hints: "/var/lib/unbound/root.hints"
# Maximum number of queries per second
ratelimit: 1000
# Defend against and print warning when reaching unwanted reply limit.
unwanted-reply-threshold: 10000
# Set EDNS reassembly buffer size to match new upstream default, as of DNS Flag Day 2020 recommendation.
edns-buffer-size: 1232
# Increase incoming and outgoing query buffer size to cover traffic peaks.
so-rcvbuf: 4m
so-sndbuf: 4m
# Hardening
harden-glue: yes
harden-dnssec-stripped: yes
harden-algo-downgrade: yes
harden-large-queries: yes
harden-short-bufsize: yes
# Privacy
use-caps-for-id: yes # Spoof protection by randomising capitalisation
rrset-roundrobin: yes
qname-minimisation: yes
minimal-responses: yes
hide-identity: yes
identity: "Server" # Purposefully a dummy identity name
hide-version: yes
# Caching
cache-min-ttl: 300
cache-max-ttl: 86400
serve-expired: yes
neg-cache-size: 4M
prefetch: yes
prefetch-key: yes
msg-cache-size: 50m
rrset-cache-size: 100m
Honestly I don’t understand the problem? The issue is that dig is not working? This is correct as dig is part of dnsutils package, which is not intalled by default. You need to install it manually
apt install dnsutils
According your information unbound service is working fine > Active: active (running)
One addition, when I am in the Adguard interface I always get an error:
Error: control/version.json | Couldn't get version check json from https://static.adguard.com/adguardhome/release/version.json: *fmt.wrapError updater: HTTP GET https://static.adguard.com/adguardhome/release/version.json: Get "https://static.adguard.com/adguardhome/release/version.json": read udp 127.0.0.1:48380->127.0.0.1:5335: i/o timeout | 502
You can’t start another instance of unbound as the service already running. You would need to stop unbound service first before running from CLI. Therefore you get address already in use.
let’s try to debug it further and install tcpdump
apt install tcpdump
once done, you can do some tracing on DNS server ports
tcpdump -i any -c500 -nn port 53 or port 5335 or port 853
This will capture 500 lines before it stop automatically. Or once cancelled by user.
Open a 2nd SSH session to perform the test using dig
i was having similar symptoms for months after an isp change. elusive, intermittent failures. certain sites faring well, others almost unusable. then a day later, seemingly random redistribution of problematic sites and working sites.
figured out my isp was handing out ip6 and ip4 addresses to dhcp clients, while only allowing port 53 traffic over ip4 for some ungodly reason.
SOLVED: putting “do-ip6: no” in unbound.conf cleared everything right up. AAAA records still come back but everything port 53 up and downstream of my resolver now happens over ip4.
sadly i guess i cannot access any of the zero domains known to me with their authoritative nameservers only available via ip6 unless i use my isps cache (lazy bums actually only offer up google’s in the dhcp response anyway; no thank you)
