The unbound.service is running without errors and I switched the custom DNS on the Pihole Panel
I also followed the page on github (https://github.com/MichaIng/DietPi/issues/2409) where someone from the Dietpi community posted a similar issue, but I didn’t found any solution to my problem.
This is my config
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
prefer-ip6: no
# 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: no # 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
The DoT configuration was one of my next options it worked!
; <<>> DiG 9.16.22-Raspbian <<>> @127.0.0.1 -p 5335 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4522
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.184.78
;; Query time: 300 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Thu Feb 03 21:25:31 CET 2022
;; MSG SIZE rcvd: 55
With DoT configuration the custom DNS seems to work smooth with unbound and my DNS requests are also encrypted now
Thank you very much, I wonder why before of the DoT configuration, the custom DNS couldn’t not resolve any query.
looks like DNS communication between Unbound and Upstream DNS was not working well. Do you have any special network component like a firewall or something that could inspect DNS request?
Actually I don’t think so. The only ploblem could be my ISP (custom) router that doesn’t allow to change the DNS from the router itself: for this reason I use the Pihole like a DHCP server (shutting down the DHCP server of the ISP router). I don’t know if this kind of routing can give some problem with the DNS request who came from the Pihole. Maybe not.
Hi guys, sorry if I re-open the thread, but I have studied a little better how unbound works.
Using DoT with unbound makes the upstream forwarded to public DNS, I’d like to use the recursive method instead.
At the moment the local DNS 127.0.0.1 on port 5335 still doesn’t resolve any address. I also ran
unbound-checkconf
to check some error in the config file but no error occured. Someone has some other hint to make recursive unbound works? Thank you.
Not sure what is causing this. For me this looks like local network or the ISP who has an influence on the DNS resolution between Unbound ans upstream DNS root server. You could test a global upstream DNS directly that failed on unbound.
from your tcpdump snap shot
20:33:52.431494 eth0 Out IP 192.168.1.6.7918 > 199.9.14.201.53: 41082% [1au] NS? . (28)
20:33:52.432779 eth0 In IP 199.9.14.201.53 > 192.168.1.6.7918: 41082 ServFail 0/0/0 (17)
I don’t think so. Because unbound is going to ask root DNS server nas you can see on tcpdump output. But something is wrong on communication between unbound and root DNS server. But I don’t know what. Maybe you would need to contact unbound guys directly or via their support platform to have a deeper look.
it worked!
