Queries not forwarded to Unbound

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]


Are you running Arch?

forward-dest would return statistics for the last 24 hours.
If you ran that command immediately after you finished your unbound configuration, there is an (albeit slim) chance that your unbound wouldn't yet have been put to duty back then.

It's far more likely your issue is related to "dns settings not being saved" in Arch-Linux as mentioned by you, though.

With a stock Pi-hole, you might be able to run pihole -r with Reconfigure and provide unbound as a Custom DNS server when prompted for selecting an Upstream DNS Provider.

But please note that Arch-Linux itself is not supported by Pi-hole:

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (Pi-hole - ArchWiki ) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.Arch-Linux runs their own support for Pi-hole

(quoting Arch-Linux' docs)

So I do not know whether this work-around for failing Arch-Linux DNS settings would work on Arch-Linux. :wink:

I am running Arch indeed :slight_smile:

Yes, totally aware Pi-Hole isn't supported on Arch (which is a bummer since it's such a good piece of software), but I was able to pin point the problem.

Turns out the culprit was dnsmasq all along!
When Pi-Hole was installed it removed the old dnsmasq.conf and replaced it with its own flavor, thus, inside the folder dnsmasq.d/ there were 2 files: 01-pihole.conf and servers.conf.

The 01-pihole.conf had the proper entries:

addn-hosts=/etc/pihole/custom.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/run/log/pihole/pihole.log
local-ttl=2
log-async
# If a DHCP client claims that its name is "wpad", ignore that.
# This fixes a security hole. see CERT Vulnerability VU#598349
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
server=127.0.0.1#5335
domain-needed
expand-hosts
interface=wlan0
server=/use-application-dns.net/

You can see the Unbound server listed there, however... the servers file had the Google dns servers in there all along!

#server=8.8.8.8
#server=8.8.4.4

All I had to do was to comment the entries to make them null, thus having the local dns resolver do its job. All in all, it was in effect an error on php8 not saving the proper settings to the file.

echo ">forward-dest >quit" | nc localhost 4711
-2 20.29 blocklist blocklist
-1 6.63 cache cache
0 73.08 127.0.0.1#5335 localhost#5335

Thanks for all the help given in advance and hoping one day you guys would add support for other Linux flavors out there. Kudos!

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.