RPI image not resolving DNSSEC (recursive server)

[fede843]

Describe the bug RPI image does not resolve insecure DNS properly when used as recursive server.

To Reproduce Steps to reproduce the behaviour:

1. Composite file:

   unbound:
   image: mvance/unbound-rpi:1.17.0
   container_name: unbound
   hostname: unbound
   restart: always
   volumes:
   - /home/pi/docker/volumes/unbound:/opt/unbound/etc/unbound
   networks:
     mainnet:
       ipv4_address: 172.20.0.10 # Used in Pi-Hole "Upstream DNS Servers" config
   ports:
     - "5335:53/tcp"
     - "5335:53/udp"

2. Customizations (config files)

   server:
   logfile: "/opt/unbound/etc/unbound/unbound.log"
   verbosity: 2
   port: 53
   do-ip4: yes
   do-udp: yes
   do-tcp: yes
   do-ip6: no
   prefer-ip6: no
   root-hints: "/opt/unbound/etc/unbound/root.hints"
   harden-glue: yes
   harden-dnssec-stripped: yes
   use-caps-for-id: no
   edns-buffer-size: 1232
   prefetch: yes
   num-threads: 1
   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
   access-control: 172.16.0.0/12 allow_snoop
   interface: 0.0.0.0@53
   chroot: "/opt/unbound/etc/unbound"
   directory: "/opt/unbound/etc/unbound"
   auto-trust-anchor-file: "var/root.key"
   tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
   cache-max-ttl: 86400
   cache-min-ttl: 300
   remote-control:
   control-enable: no

Expected behavior Running from the host RPI system:

dig fail01.dnssec.works @127.0.0.1 -p 5335

; <<>> DiG 9.16.37-Debian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46756
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works.       IN  A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Feb 14 09:55:58 -03 2023
;; MSG SIZE  rcvd: 48

Error messages Running from the host RPI system:

dig fail01.dnssec.works @127.0.0.1 -p 5335 +trace

; <<>> DiG 9.16.37-Debian <<>> fail01.dnssec.works @127.0.0.1 -p 5335 +trace
;; global options: +cmd
.           86317   IN  NS  j.root-servers.net.
.           86317   IN  NS  k.root-servers.net.
.           86317   IN  NS  l.root-servers.net.
.           86317   IN  NS  m.root-servers.net.
.           86317   IN  NS  a.root-servers.net.
.           86317   IN  NS  b.root-servers.net.
.           86317   IN  NS  c.root-servers.net.
.           86317   IN  NS  d.root-servers.net.
.           86317   IN  NS  e.root-servers.net.
.           86317   IN  NS  f.root-servers.net.
.           86317   IN  NS  g.root-servers.net.
.           86317   IN  NS  h.root-servers.net.
.           86317   IN  NS  i.root-servers.net.
.           86317   IN  RRSIG   NS 8 0 518400 20230227050000 20230214040000 951 . VXSm59w17QNYoRwEE0GiV2q7+rjstTER5+axR8/FdNNUGy4CeRkgNsde Hf8Z7w76aAev6NeZeRIAkhQBDzxlqruMR1t+7u3X+d+xp1eF9qib4Avd v8FnnHE1kUN8/uux6kN8vZ+aBM4eZ9pCyC2XdRz2IKVNsDOrasxEMl1x E0hBDD6EU/KPYwOiAf+B1XeKtSYf640mdG4FEgdhKvjeV1TofcMjZT9e KNEUoSi7oQqQEYllR/58TcoOf0S8zo1U9YnRniG9NzW30XjIXeZ9VK5U LdQ++X9oMP1foSvV7jpuSr8fxmqqjT7+zx/Wg/tTByTgxCPp2fNCbjmt AVXwtg==
;; Received 525 bytes from 127.0.0.1#5335(127.0.0.1) in 15 ms

;; connection timed out; no servers could be reached

Additional context Host RPI is

Linux raspberrypi 6.1.11-v8+ #1630 SMP PREEMPT Fri Feb 10 12:11:31 GMT 2023 aarch64 GNU/Linux

To add more into this, it works intermittently. At random intervals it resolves as expected, and many other times it does not. Maybe a missconfiguration on my side?

[hqnicolas]

dear friend, you are sending request to 127.0.0.1 LOCAL MACHINE you need to send this request to 192.168.0.XXX THE CONTAINER

[fede843]

Hi @hqnicolas thanks for reaching out.

I am using dig from the raspberry host itself. Also I am mapping 5335 port to the internal resolver. Request to my local RPI are passed trough unbound container this way. I am using this setup exposing the port externally just for testing purposes.