Firmware >=4.8.4 Resolution Issues with Unbound Recursive dns server

Although I realize that Unbound can be installed on the router (Flint2 in my case with firmware 4.9.0) I prefer to have it installed on my RPi since it is basically unused and provides different aspects regarding “control”.

I have tried many different “options” but cannot get unbound and the Flint 2 to cooporate, at least not configuring Unbound to be a recursive server, not forwarding, can get forwarding to work For me, forwarding server adds no value.

Performing dig @127.0.0.1 example.com always returns a SERVFAIL. Without a firewall>traffic rule (listed below) dig times out. Enabling the firewall>traffic rule no longer timesout but does return SERVFAIL.

I can DIG a single root server with and without the firewall rule enabled:
dig @198.41.0.4 version.bind CH TXT +udp with status: NOTIMP but dig @198.41.0.4 version.bind CH TXT +tcp has status: SERVFAIL;
and can get list of rootservers using dig @198.41.0.4 . NS +udp returns status: NOERROR along with list of root servers

but when performing resolution, Unbound queries a large block (I think that’s how it works) and this is where the failure occurs (dig….)

Seems that GL-iNet routers aggressively block port 53 (which is required by Unbound), I created a firewall rule using Luci allowing the Rpi’s IP. However, even with this rule enabled, I still receive SERVFAIL from a standard dig @127.0.0.1 example.com

I am trying to learn how to bypass this issue or understand where I am going wrong with the setup so that I can correct and use Unbound in recursive mode.

Searches do suggest that there is a “known” bug in GL-iNet router firmware versions 4.8.4 through 4.9.0 where UDP/53 reverse-NAT silently drops responses to specific LAN clients after a WAN IP rotation or due to conntrack inconsistencies. Although a dig test to a single root server may work, Unbound's "prime" process requires stable UDP communication with multiple root servers to build the delegation chain, which the Flint 2 is likely disrupting.

I have verified that UDP connectivity works for single queries but fails with failed to get a delegation. Based on searches this suggests that the “router's stateful firewall is likely dropping the subsequent responses required for the full recursive handshake”

Any help would be appreciated and if you would like / need further details beyond what is listed below, please ask and I will do my best to provide.

Current setup:
Flint 2 with 4.9.0 and basic setup
DNS Rebinding Protection: Disabled
Override DNS Settings of all clients: enabled (have also tried with it disabled to no avail)
Firewall > Traffic Rule added via Luci:
Protocols: TCP and UDP
Source Zone: Any Zone (forward)
Source Address: RPI/Unbound IP (it is a static IP)
Source Port: any
Destination Zone: wan
Destination Address:
Destination port: 53
Action: accept

RPI 4b 2GB running Debian/Trixie

Unbound:
version 1.22.0
Installed native (sudo apt install unbound), Not Docker
Very basic .conf file contents:
server:
interface: 0.0.0.0
interface: 127.0.0.1
access-control: 192.168.xxx.0/24 allow
access-control: 127.0.0.0/8 allow
auto-trust-anchor-file: "/var/lib/unbound/root.key"
root-hints: "/var/lib/unbound/root.hints"
do-not-query-localhost: no
do-ip4:yes
do-ip6:no
qname-minimisation: yes

Hi,

We recommend the following:

  1. Disable Network > DNS > Override DNS Settings of All Clients. Otherwise, all DNS traffic will be redirected to the router’s DNS, which will naturally prevent Unbound from working properly.
  2. The firewall rule should not be necessary. We do not block LAN devices from accessing external UDP port 53.

Please also check the following:

  1. Although AdGuard Home > Handle Client Requests does not affect LAN devices accessing external UDP port 53, we still recommend disabling it, or disabling AdGuard Home entirely.

  2. If you are using a VPN, Tailscale Exit Node, or similar features, we recommend disabling them temporarily to avoid any possible interference between their network routing and the authoritative DNS servers.

  3. You can SSH into the router and run the following command to simulate how a recursive DNS server works, and check whether your ISP is hijacking DNS traffic and causing the failure:

    dig +trace google.com
    

    Expected result: