Pi-hole with Unbound failing to resolve on OpenWrt network

Recently I installed OpenWrt on my Archer C50 v4 using tftp. The installation was relatively smooth and the router is working.

Before switching to OpenWrt, my Pi was resolving queries without any issues and everything worked as intended. I have configured the router to use Pi-hole by setting Network > Interfaces > LAN > DHCP Server > Advanced Settings > DHCP-Options to 6,10.0.0.35 (10.0.0.35 being my Pi's internal IP).

The router is located at 10.0.0.1, my subnet is 255.0.0.0, DHCP starts handing out IP addresses at 10.0.2.0 and stops somewhere at 10.0.255.0 or 10.0.255.255.

I have also enabled the Log queries option in order to debug.

/etc/config/dhcp on router

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option localservice '1'
        option ednspacket_max '1232'
        option logqueries '1'

config dhcp 'lan'
        option interface 'lan'
        option start '512'
        option limit '64768'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'
        list dhcp_option '6,10.0.0.35'
        option dns_service '0'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'
        list ra_flags 'none'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

/etc/config/network on router

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdd9:0047:1730::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '60'
        option ipaddr '10.0.0.1'
        option netmask '255.0.0.0'

config device
        option name 'eth0.2'
        option macaddr '1c:3b:f3:f1:3f:3a'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'
        option peerdns '0'
        list dns '1.1.1.1'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 6t'

output of dig eff.org @127.0.0.1 -p 5335 on pi (unbound runs on port 5335)

; <<>> DiG 9.16.22-Raspbian <<>> eff.org @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1827
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;eff.org.                       IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Wed Dec 29 13:21:39 GMT 2021
;; MSG SIZE  rcvd: 36

/var/log/unbound/unbound.log on pi

(password is openwrt)

I have tried fiddling with the settings getting it to work, I found this (https://www.reddit.com/r/pihole/comments/mu7eyy/attempting_to_connect_pihole_recursive_dns_on/) but it wasn't particularly helpful.

I reset the router and wiped the pi in desperation and nothing worked.
If any other config files or logs are required, please ask
Also please confirm if I am doing things correctly or everything about my setup is inherently wrong :sweat_smile:

All help is appreciated,
Thanks in advance

Same config here, and works fine. my ouput:

root@ray308-pihole:/# dig eff.org @127.0.0.1 -p 5335

; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> eff.org @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48226
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;eff.org.                       IN      A

;; ANSWER SECTION:
eff.org.                7200    IN      A       173.239.79.196

;; Query time: 259 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Wed Dec 29 15:46:51 CET 2021
;; MSG SIZE  rcvd: 52

root@ray308-pihole:/# 

The only thing I see in your dhcp config is that is misssing in my config.

option dns_service '0'
1 Like

I've removed that option and rebooted my router but the issue persists.

Just to confirm, Pi-hole works with 1.1.1.1 as the upstream server.
I have installed unbound on my main computer and it seems to work fine on the network, I have also noticed that very rarely Unbound successfully resolves a single domain then stops working again.

I placed the pi on my main, non-OpenWrt network and it resolves all domains successfully.

I've no clue as to what is going on. My OpenWrt install is fresh as I reset it this morning.

Thanks for the reply

When I set 1.1.1.1 as the upstream server on pihole, https://1.1.1.1/help says I'm not connected to 1.1.1.1

( my results: https://1.1.1.1/help#eyJpc0NmIjoiTm8iLCJpc0RvdCI6Ik5vIiwiaXNEb2giOiJObyIsInJlc29sdmVySXAtMS4xLjEuMSI6IlllcyIsInJlc29sdmVySXAtMS4wLjAuMSI6IlllcyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjExMTEiOiJObyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjEwMDEiOiJObyIsImRhdGFjZW50ZXJMb2NhdGlvbiI6Ik1BTiIsImlzV2FycCI6Ik5vIiwiaXNwTmFtZSI6IkNsb3VkZmxhcmUiLCJpc3BBc24iOiIxMzMzNSJ9 )

It seems like OpenWrt is proxying my DNS for some reason.
I'm not sure if the list dns '1.1.1.1' option in config interface 'wan' has anything to do with it

Edit: The same results for the 1.1.1.1 connectivity check appear when using Quad9 as the upstream DNS in Pihole

Should I perform a reset again?

Verify there are no DNS Intercept/Hijacking firewall rules on the router that would interfere with Unbound.

Post the unbound.conf config. What device is fdd9:47:1730::bc6 on your LAN?

1 Like

From what I recall that is my raspberry pi. Apologies but I reset just before seeing your message so I'll have to check again

Thanks

Ok - just reset and the issue with unbound persists. Only changes I made were the network subnet and the dhcp range.

Pi ip address

pi@raspberrypi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:30:26:a9 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.35/8 brd 10.255.255.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fd31:a76a:110b::bc6/128 scope global dynamic noprefixroute
       valid_lft 43026sec preferred_lft 43026sec
    inet6 fd31:a76a:110b:0:5f84:3bd7:5078:5669/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::6fd6:3cc:bce6:17b3/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:65:73:fc brd ff:ff:ff:ff:ff:ff

/etc/unbound/unbound.conf.d/pi-hole.conf (source: https://docs.pi-hole.net/guides/dns/unbound/)

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 5

    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.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # 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 enhanceme
nt 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

edit: /etc/config/firewall on newly-reset router:

config defaults
        option syn_flood        1
        option input            ACCEPT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

config rule
        option name             Allow-IGMP
        option src              wan
        option proto            igmp
        option family           ipv4
option target           ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option src_ip           fc00::/6
        option dest_ip          fc00::/6
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-MLD
        option src              wan
        option proto            icmp
        option src_ip           fe80::/10
        list icmp_type          '130/0'
        list icmp_type          '131/0'
        list icmp_type          '132/0'
        list icmp_type          '143/0'
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto    icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

config rule
        option name             Allow-IPSec-ESP
        option src              wan
        option dest             lan
        option proto            esp
        option target           ACCEPT

config rule
        option name             Allow-ISAKMP
        option src              wan
        option dest             lan
        option dest_port        500
        option proto            udp
        option target           ACCEPT

# allow interoperability with traceroute classic
# note that traceroute uses a fixed port range, and depends on getting
# back ICMP Unreachables.  if we're operating in DROP mode, it won't
# work so we explicitly REJECT packets on these ports.
config rule
        option name             Support-UDP-Traceroute
        option src              wan
        option dest_port        33434:33689
        option proto            udp
        option family           ipv4
        option target           REJECT
        option enabled          false

# include a file with users custom iptables rules
config include
        option path /etc/firewall.user


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option dest             wan
#       option proto    tcp
#       option target   REJECT

# block a specific mac on wan
#config rule
#       option dest             wan
#       option src_mac  00:11:22:33:44:66
#       option target   REJECT

# block incoming ICMP traffic on a zone
#config rule
#       option src              lan
#       option proto    ICMP
#       option target   DROP

# port redirect port coming in on wan to lan
#config redirect
#       option src                      wan
#       option src_dport        80
#       option dest                     lan
#       option dest_ip          192.168.16.235
#       option dest_port        80
#       option proto            tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#       option src              wan
#       option src_dport        22001
#       option dest             lan
#       option dest_port        22
#       option proto            tcp

### FULL CONFIG SECTIONS
#config rule
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port 80
#       option dest             wan
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp
#       option target   REJECT

#config redirect
#       option src              lan
#       option src_ip   192.168.45.2
#       option src_mac  00:11:22:33:44:55
#       option src_port         1024
#       option src_dport        80
#       option dest_ip  194.25.2.129
#       option dest_port        120
#       option proto    tcp

I seem to have fixed it, thanks for all the help. Basically unbound-resolvconf (automatically installed) was creating /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf which was being sourced by /etc/unbound/unbound.conf.

/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf was forwarding lookups to the router's IPv6 address

By disabling and stopping unbound-resolvconf, the issue seems to have been solved
sudo systemctl disable unbound-resolvconf
sudo systemctl stop unbound-resolvconf

I can't believe I spent over two days trying to sort this out when it was this simple.
Again, thanks for the help! I was looking in the router's settings which was working as intended when the issue was right under my nose. :joy: Geez.

Edit: The file kept coming back with the router's IPv6 address. To circumvent this, I set static domain_name_servers=1.1.1.1 9.9.9.9 in /etc/dhcpcd.conf. Also, I set Network > Interfaces > LAN > DHCP Server > IPv6 Settings > Local IPv6 DNS server to off in OpenWrt's settings.

1 Like

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