Expected Behaviour:
Queries should be forwarded to Unbound on local port 127.0.0.1:5335
Actual Behaviour:
Queries instead are being redirected to Upstream Google Server (dns.google#53)
Unbound is configured correctly and resolving queries:
ā unbound.service - Validating, recursive, and caching DNS resolver
Loaded: loaded (/etc/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2021-05-07 20:30:49 CDT; 37min ago
Docs: man:unbound(8)
Main PID: 725 (unbound)
Tasks: 1 (limit: 4915)
CPU: 379ms
CGroup: /system.slice/unbound.service
āā725 /usr/bin/unbound -d -p -v
May 07 20:30:49 piboi systemd[1]: Starting Validating, recursive, and caching DNS resolver...
May 07 20:30:49 piboi unbound[725]: [1620437449] unbound[725:0] notice: Start of unbound 1.13.1.
May 07 20:30:49 piboi unbound[725]: [1620437449] unbound[725:0] debug: chdir to /etc/unbound
May 07 20:30:49 piboi unbound[725]: [1620437449] unbound[725:0] debug: chroot to /etc/unbound
May 07 20:30:49 piboi unbound[725]: [1620437449] unbound[725:0] debug: drop user privileges, run as unbound
May 07 20:30:49 piboi unbound[725]: [1620437449] unbound[725:0] debug: switching log to /etc/unbound/unbound.log
May 07 20:30:49 piboi systemd[1]: Started Validating, recursive, and caching DNS resolver.
Nevertheless, after setting the Upstream DNS server to Custom 127.0.0.1#5335 entries are still being redirected to Google dns upstream servers for some reason on port #53.
echo ">forward-dest >quit" | nc localhost 4711
-2 15.28 blocklist blocklist
-1 21.45 cache cache
0 63.27 8.8.4.4#53 dns.google#53
Have configured Unbound per this guide.
Have tweaked it a bit to add TLS support, but not using DNSSEC.
Config file here:
server:
# If no logfile is specified, syslog is used
chroot: "/etc/unbound"
logfile: "/etc/unbound/unbound.log"
verbosity: 2
log-queries: yes
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: no
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
#harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
#use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
# SSL Certificate for encrypted traffic to Cloudfare
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
forward-zone:
name: "."
forward-tls-upstream: yes
# Cloudfare DNS
forward-addr: 1.1.1.3@853#family.cloudflare-dns.com
forward-addr: 1.0.0.3@853#family.cloudflare-dns.com
Can't think of what's really causing the problem here. Arch-Wiki mentions that there's an issue with using php8 and the dns settings not being saved, but even changing to php7 the issue persists. Also use a VPN but that doesn't seem to affect the connection at all as I have tried running Pi-hole with and without it with the same results.
If you guys could point me in the right direction I'd be grateful.
Debug Token:
[Replace this text with the debug token provided from running pihole -d (or running the debug script through the web interface]
