Adguard + Unbuond Configuration ISSUE

pietromezza · 15 December 2022 00:14

Creating a bug report/issue

Required Information

DietPi version |

G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=11
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘not applicable’

Distro version | bullseye
Kernel version | ux DietPi 5.15.80-rockchip64 #22.11.1 SMP PREEMPT Wed Nov 30 11:12:47 UTC 2022 aarch64 GNU/Linux
SBC model | ROCKPro64 (aarch64)
Power supply used | DC 12V 3A
SD card used | SanDisk ultra

Additional Information (if applicable)

Software title | ADH + Unbuond + (pivpn wireguard)
Was the software title installed freshly or updated/migrated? freshly
Can this issue be replicated on a fresh installation of DietPi? yes
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | echo $G_HW_UUID

I resume all the point here… so:

After installing adguard and unbound the server no longer responds to my dns requests

As U know when you install adguard and unbound you go to generate the file and insert automatically inside ADH “Configured on /mnt/dietpi_userdata/adguardhome/dietpi-unbound.conf”
in the file there is this address 127.0.0.1:5335 when I try to “ping www.google.it” it fails to resolve it

systemctl status unbound :

Dec 14 21:17:27 DietPi systemd[1]: Starting Unbound DNS server...
Dec 14 21:17:28 DietPi unbound[868]: [1671049048] unbound[868:0] warning: so-rcvbuf 4194304 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 14 21:17:28 DietPi unbound[868]: [1671049048] unbound[868:0] warning: so-sndbuf 4194304 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 14 21:17:28 DietPi unbound[868]: [868:0] info: start of service (unbound 1.13.1).
Dec 14 21:17:28 DietPi systemd[1]: Started Unbound DNS server.

DietPi:~# dig @127.0.0.1 -p 5335 dietpi.com  
<<>> DiG 9.16.33-Debian <<>> @127.0.0.1 -p 5335 dietpi.com 
; (1 server found)  
;; global options: +cmd
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33104  
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1  
;; OPT PSEUDOSECTION:     
; EDNS: version: 0, flags:; udp: 1232  
;; QUESTION SECTION:    
;dietpi.com.                    IN      A    
;; Query time: 52 msec             
;; SERVER: 127.0.0.1#5335(127.0.0.1)  
;; WHEN: Wed Dec 14 22:29:09 CET 2022       
;; MSG SIZE  rcvd: 39

ss -tulpn | grep LISTEN

tcp   LISTEN 0    4096  *:53     :users:(("AdGuardHome",pid=816,fd=12))

Closing this thing where to excuse the ignorance maybe I’m getting lost in a stupid thing, thx

Jappe · 15 December 2022 00:36

Is this the whole output from ss -tulpn | grep LISTEN?
If yes, then unbound is not listening at all.

Can you do:

sudo systemctl stop unbound
sudo unbound -vvvvv

Can you post the output of it?
After this, you can stop unbound with the keys ctrl + c and then start unbound again via systemctl:
sudo systemctl start unbound

With AdGuard I have no experience, maybe you can check the web UI for hints, it’s reachable at http://<IP_of_your_RockPro>:8083

Joulinar · 15 December 2022 07:38

How did you install AGH + unbound? Using dietpi-software there should be nothing to configure, copy or generate. Our script will do the entire configuration and it should work ootb.

doubt this was the whole output. Otherwise SSH server would be missing Usually it should looks like this

root@DietPiR5S:~# ss -tulpn | grep LISTEN
tcp   LISTEN 0      1000         0.0.0.0:22        0.0.0.0:*    users:(("dropbear",pid=366,fd=4))
tcp   LISTEN 0      256        127.0.0.1:5335      0.0.0.0:*    users:(("unbound",pid=1823,fd=4))
tcp   LISTEN 0      256        127.0.0.1:8953      0.0.0.0:*    users:(("unbound",pid=1823,fd=6))
tcp   LISTEN 0      4096               *:8083            *:*    users:(("AdGuardHome",pid=2257,fd=9))
tcp   LISTEN 0      4096               *:53              *:*    users:(("AdGuardHome",pid=2257,fd=12))
tcp   LISTEN 0      1000            [::]:22           [::]:*    users:(("dropbear",pid=366,fd=5))
tcp   LISTEN 0      256            [::1]:8953         [::]:*    users:(("unbound",pid=1823,fd=5))
root@DietPiR5S:~#

pietromezza:

Dec 14 21:17:28 DietPi unbound[868]: [1671049048] unbound[868:0] warning: so-rcvbuf 4194304 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 14 21:17:28 DietPi unbound[868]: [1671049048] unbound[868:0] warning: so-sndbuf 4194304 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.

How does the service has been started?

pietromezza · 15 December 2022 08:36

Thx Jappe for responding
Adguard works fine without unbound
Tell me what else I could do to help you better thanks

root@DietPi:~# sudo systemctl stop unbound
root@DietPi:~# sudo unbound -vvvvv
[1671092855] unbound[36278:0] notice: Start of unbound 1.13.1.
[1671092855] unbound[36278:0] debug: increased limit(open files) from 1024 to 24770
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating udp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 5335
[1671092855] unbound[36278:0] debug: creating tcp4 socket 127.0.0.1 8953
[1671092855] unbound[36278:0] debug: setup SSL certificates
[1671092855] unbound[36278:0] debug: switching log to syslog

pietromezza · 15 December 2022 08:46

Thanks for answering me and fixing my question, so I tried to install using the dietpi-software tool but nothing even if I see that the path is configured in the ADH settings

I also tried manually setting it up but it didn’t work

I filtered, all the output :

root@DietPi:~# ss -tulpn | grep LISTEN
tcp   LISTEN 0      4096          0.0.0.0:111        0.0.0.0:*    users:(("rpcbind",pid=494,fd=4),("systemd",pid=1,fd=32))
tcp   LISTEN 0      1024          0.0.0.0:80         0.0.0.0:*    users:(("lighttpd",pid=1574,fd=4))
tcp   LISTEN 0      4096        127.0.0.1:8080       0.0.0.0:*    users:(("crowdsec",pid=1531,fd=13))
tcp   LISTEN 0      128           0.0.0.0:51413      0.0.0.0:*    users:(("transmission-da",pid=1581,fd=15))
tcp   LISTEN 0      4096        127.0.0.1:36117      0.0.0.0:*    users:(("casaos-gateway",pid=966,fd=10))
tcp   LISTEN 0      1000          0.0.0.0:22         0.0.0.0:*    users:(("dropbear",pid=719,fd=4))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=14))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=12))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=10))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=8))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=6))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=4))
tcp   LISTEN 0      4096          0.0.0.0:3000       0.0.0.0:*    users:(("docker-proxy",pid=1846,fd=4))
tcp   LISTEN 0      5             0.0.0.0:8888       0.0.0.0:*    users:(("rpimonitord",pid=1625,fd=5))
tcp   LISTEN 0      256         127.0.0.1:8953       0.0.0.0:*    users:(("unbound",pid=36280,fd=15))
tcp   LISTEN 0      4096          0.0.0.0:3001       0.0.0.0:*    users:(("docker-proxy",pid=1825,fd=4))
tcp   LISTEN 0      4096        127.0.0.1:45529      0.0.0.0:*    users:(("casaos-user-ser",pid=1265,fd=7))
tcp   LISTEN 0      50            0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1346,fd=48))
tcp   LISTEN 0      4096        127.0.0.1:40993      0.0.0.0:*    users:(("casaos-message-",pid=1158,fd=7))
tcp   LISTEN 0      128           0.0.0.0:9091       0.0.0.0:*    users:(("transmission-da",pid=1581,fd=14))
tcp   LISTEN 0      4096        127.0.0.1:45027      0.0.0.0:*    users:(("casaos",pid=987,fd=9))
tcp   LISTEN 0      4096        127.0.0.1:41865      0.0.0.0:*    users:(("casaos-app-mana",pid=1250,fd=7))
tcp   LISTEN 0      4096        127.0.0.1:39497      0.0.0.0:*    users:(("casaos-gateway",pid=966,fd=7))
tcp   LISTEN 0      80          127.0.0.1:3306       0.0.0.0:*    users:(("mariadbd",pid=1466,fd=20))
tcp   LISTEN 0      511         127.0.0.1:6379       0.0.0.0:*    users:(("redis-server",pid=1394,fd=7))
tcp   LISTEN 0      50            0.0.0.0:139        0.0.0.0:*    users:(("smbd",pid=1346,fd=49))
tcp   LISTEN 0      4096        127.0.0.1:6060       0.0.0.0:*    users:(("crowdsec",pid=1531,fd=52))
tcp   LISTEN 0      4096        127.0.0.1:40653      0.0.0.0:*    users:(("casaos-local-st",pid=1384,fd=8))
tcp   LISTEN 0      4096             [::]:111           [::]:*    users:(("rpcbind",pid=494,fd=6),("systemd",pid=1,fd=34))
tcp   LISTEN 0      1024             [::]:80            [::]:*    users:(("lighttpd",pid=1574,fd=5))
tcp   LISTEN 0      4096                *:81               *:*    users:(("casaos-gateway",pid=966,fd=8))
tcp   LISTEN 0      4096                *:8083             *:*    users:(("AdGuardHome",pid=815,fd=9))
tcp   LISTEN 0      128              [::]:51413         [::]:*    users:(("transmission-da",pid=1581,fd=16))
tcp   LISTEN 0      4096                *:53               *:*    users:(("AdGuardHome",pid=815,fd=13))
tcp   LISTEN 0      1000             [::]:22            [::]:*    users:(("dropbear",pid=719,fd=5))
tcp   LISTEN 0      4096             [::]:3000          [::]:*    users:(("docker-proxy",pid=1853,fd=4))
tcp   LISTEN 0      4096             [::]:3001          [::]:*    users:(("docker-proxy",pid=1833,fd=4))
tcp   LISTEN 0      50               [::]:445           [::]:*    users:(("smbd",pid=1346,fd=46))
tcp   LISTEN 0      511             [::1]:6379          [::]:*    users:(("redis-server",pid=1394,fd=8))
tcp   LISTEN 0      50               [::]:139           [::]:*    users:(("smbd",pid=1346,fd=47))
tcp   LISTEN 0      4096                *:33293            *:*    users:(("casaos",pid=987,fd=10))

“How does the service has been started?”
The service has been started automatically
I’ve tried restarting it multiple times

root@DietPi:~# sudo systemctl status unbound
● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
    Drop-In: /etc/systemd/system/unbound.service.d
             └─dietpi.conf
     Active: active (running) since Thu 2022-12-15 09:42:23 CET; 2min 55s ago
       Docs: man:unbound(8)
    Process: 946 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 996 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
   Main PID: 1016 (unbound)
      Tasks: 6 (limit: 4464)
     Memory: 28.8M
        CPU: 1.153s
     CGroup: /system.slice/unbound.service
             └─1016 /usr/sbin/unbound -d -p

Dec 15 09:42:23 DietPi unbound[1016]: [1671093743] unbound[1016:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 15 09:42:23 DietPi unbound[1016]: [1671093743] unbound[1016:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 15 09:42:23 DietPi unbound[1016]: [1671093743] unbound[1016:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 15 09:42:23 DietPi unbound[1016]: [1671093743] unbound[1016:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 15 09:42:23 DietPi unbound[1016]: [1671093743] unbound[1016:0] warning: so-rcvbuf 1048576 was not granted. Got 425984. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.
Dec 15 09:42:23 DietPi unbound[1016]: [1016:0] notice: init module 0: subnet
Dec 15 09:42:23 DietPi unbound[1016]: [1016:0] notice: init module 1: validator
Dec 15 09:42:23 DietPi unbound[1016]: [1016:0] notice: init module 2: iterator
Dec 15 09:42:23 DietPi unbound[1016]: [1016:0] info: start of service (unbound 1.13.1).
Dec 15 09:42:23 DietPi systemd[1]: Started Unbound DNS server.
root@DietPi:~#

Thx

Joulinar · 15 December 2022 08:53

pietromezza:

tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=14))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=12))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=10))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=8))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=6))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=36280,fd=4))

quite some unbound processes. But it seems too much. Can you reboot your system and check again

s -tulpn | grep LISTEN

My guess, unbound has issues to connect to root DNS server. Somethig we could verify after reboot.

pietromezza · 15 December 2022 09:00

I can tell you that I tried so many times to reinstall unbound so maybe it’s a bit dirty?

I reboot the system but i think is the same

root@DietPi:~# ss -tulpn | grep LISTEN
tcp   LISTEN 0      50           0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1251,fd=48))
tcp   LISTEN 0      4096       127.0.0.1:42143      0.0.0.0:*    users:(("casaos-local-st",pid=1302,fd=9))
tcp   LISTEN 0      4096       127.0.0.1:38849      0.0.0.0:*    users:(("casaos-gateway",pid=950,fd=7))
tcp   LISTEN 0      128          0.0.0.0:9091       0.0.0.0:*    users:(("transmission-da",pid=1469,fd=14))
tcp   LISTEN 0      80         127.0.0.1:3306       0.0.0.0:*    users:(("mariadbd",pid=1383,fd=20))
tcp   LISTEN 0      511        127.0.0.1:6379       0.0.0.0:*    users:(("redis-server",pid=1312,fd=7))
tcp   LISTEN 0      50           0.0.0.0:139        0.0.0.0:*    users:(("smbd",pid=1251,fd=49))
tcp   LISTEN 0      4096       127.0.0.1:36971      0.0.0.0:*    users:(("casaos-app-mana",pid=1205,fd=8))
tcp   LISTEN 0      4096       127.0.0.1:44811      0.0.0.0:*    users:(("casaos",pid=971,fd=11))
tcp   LISTEN 0      4096       127.0.0.1:38923      0.0.0.0:*    users:(("casaos-message-",pid=1113,fd=7))
tcp   LISTEN 0      4096       127.0.0.1:6060       0.0.0.0:*    users:(("crowdsec",pid=1450,fd=48))
tcp   LISTEN 0      4096       127.0.0.1:35981      0.0.0.0:*    users:(("casaos-gateway",pid=950,fd=10))
tcp   LISTEN 0      4096         0.0.0.0:111        0.0.0.0:*    users:(("rpcbind",pid=491,fd=4),("systemd",pid=1,fd=32))
tcp   LISTEN 0      1024         0.0.0.0:80         0.0.0.0:*    users:(("lighttpd",pid=1464,fd=4))
tcp   LISTEN 0      4096       127.0.0.1:8080       0.0.0.0:*    users:(("crowdsec",pid=1450,fd=13))
tcp   LISTEN 0      128          0.0.0.0:51413      0.0.0.0:*    users:(("transmission-da",pid=1469,fd=15))
tcp   LISTEN 0      4096       127.0.0.1:39413      0.0.0.0:*    users:(("casaos-user-ser",pid=1215,fd=7))
tcp   LISTEN 0      1000         0.0.0.0:22         0.0.0.0:*    users:(("dropbear",pid=596,fd=4))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=14))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=12))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=10))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=8))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=6))
tcp   LISTEN 0      256        127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=868,fd=4))
tcp   LISTEN 0      4096         0.0.0.0:3000       0.0.0.0:*    users:(("docker-proxy",pid=1733,fd=4))
tcp   LISTEN 0      5            0.0.0.0:8888       0.0.0.0:*    users:(("rpimonitord",pid=1525,fd=5))
tcp   LISTEN 0      4096         0.0.0.0:3001       0.0.0.0:*    users:(("docker-proxy",pid=1712,fd=4))
tcp   LISTEN 0      256        127.0.0.1:8953       0.0.0.0:*    users:(("unbound",pid=868,fd=15))
tcp   LISTEN 0      50              [::]:445           [::]:*    users:(("smbd",pid=1251,fd=46))
tcp   LISTEN 0      511            [::1]:6379          [::]:*    users:(("redis-server",pid=1312,fd=8))
tcp   LISTEN 0      50              [::]:139           [::]:*    users:(("smbd",pid=1251,fd=47))
tcp   LISTEN 0      4096               *:33293            *:*    users:(("casaos",pid=971,fd=8))
tcp   LISTEN 0      4096            [::]:111           [::]:*    users:(("rpcbind",pid=491,fd=6),("systemd",pid=1,fd=34))
tcp   LISTEN 0      1024            [::]:80            [::]:*    users:(("lighttpd",pid=1464,fd=5))
tcp   LISTEN 0      4096               *:81               *:*    users:(("casaos-gateway",pid=950,fd=8))
tcp   LISTEN 0      4096               *:8083             *:*    users:(("AdGuardHome",pid=816,fd=9))
tcp   LISTEN 0      128             [::]:51413         [::]:*    users:(("transmission-da",pid=1469,fd=16))
tcp   LISTEN 0      4096               *:53               *:*    users:(("AdGuardHome",pid=816,fd=13))
tcp   LISTEN 0      1000            [::]:22            [::]:*    users:(("dropbear",pid=596,fd=5))
tcp   LISTEN 0      4096            [::]:3000          [::]:*    users:(("docker-proxy",pid=1740,fd=4))
tcp   LISTEN 0      4096            [::]:3001          [::]:*    users:(("docker-proxy",pid=1720,fd=4))

Ok now i fixed i reinstall all and i have only once

root@DietPi:~# ss -tulpn | grep LISTEN
tcp   LISTEN 0      128           0.0.0.0:9091       0.0.0.0:*    users:(("transmission-da",pid=9547,fd=14))
tcp   LISTEN 0      4096        127.0.0.1:41225      0.0.0.0:*    users:(("casaos-app-mana",pid=1142,fd=8))
tcp   LISTEN 0      4096        127.0.0.1:40329      0.0.0.0:*    users:(("casaos",pid=995,fd=8))
tcp   LISTEN 0      80          127.0.0.1:3306       0.0.0.0:*    users:(("mariadbd",pid=9434,fd=21))
tcp   LISTEN 0      511         127.0.0.1:6379       0.0.0.0:*    users:(("redis-server",pid=9371,fd=7))
tcp   LISTEN 0      50            0.0.0.0:139        0.0.0.0:*    users:(("smbd",pid=9358,fd=49))
tcp   LISTEN 0      4096        127.0.0.1:32843      0.0.0.0:*    users:(("casaos-gateway",pid=980,fd=10))
tcp   LISTEN 0      4096        127.0.0.1:6060       0.0.0.0:*    users:(("crowdsec",pid=1379,fd=48))
tcp   LISTEN 0      4096        127.0.0.1:35181      0.0.0.0:*    users:(("casaos-gateway",pid=980,fd=7))
tcp   LISTEN 0      4096        127.0.0.1:40815      0.0.0.0:*    users:(("casaos-user-ser",pid=1148,fd=7))
tcp   LISTEN 0      4096          0.0.0.0:111        0.0.0.0:*    users:(("rpcbind",pid=499,fd=4),("systemd",pid=1,fd=122))
tcp   LISTEN 0      1024          0.0.0.0:80         0.0.0.0:*    users:(("lighttpd",pid=9535,fd=4))
tcp   LISTEN 0      4096        127.0.0.1:8080       0.0.0.0:*    users:(("crowdsec",pid=1379,fd=13))
tcp   LISTEN 0      4096        127.0.0.1:39185      0.0.0.0:*    users:(("casaos-message-",pid=1055,fd=7))
tcp   LISTEN 0      128           0.0.0.0:51413      0.0.0.0:*    users:(("transmission-da",pid=9547,fd=15))
tcp   LISTEN 0      1000          0.0.0.0:22         0.0.0.0:*    users:(("dropbear",pid=705,fd=4))
tcp   LISTEN 0      256         127.0.0.1:5335       0.0.0.0:*    users:(("unbound",pid=8328,fd=4))
tcp   LISTEN 0      4096          0.0.0.0:3000       0.0.0.0:*    users:(("docker-proxy",pid=9839,fd=4))
tcp   LISTEN 0      5             0.0.0.0:8888       0.0.0.0:*    users:(("rpimonitord",pid=9595,fd=5))
tcp   LISTEN 0      4096          0.0.0.0:3001       0.0.0.0:*    users:(("docker-proxy",pid=9817,fd=4))
tcp   LISTEN 0      256         127.0.0.1:8953       0.0.0.0:*    users:(("unbound",pid=8328,fd=5))
tcp   LISTEN 0      4096        127.0.0.1:32827      0.0.0.0:*    users:(("casaos-local-st",pid=1239,fd=9))
tcp   LISTEN 0      50            0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=9358,fd=48))
tcp   LISTEN 0      511             [::1]:6379          [::]:*    users:(("redis-server",pid=9371,fd=8))
tcp   LISTEN 0      50               [::]:139           [::]:*    users:(("smbd",pid=9358,fd=47))
tcp   LISTEN 0      4096                *:33293            *:*    users:(("casaos",pid=995,fd=9))
tcp   LISTEN 0      4096             [::]:111           [::]:*    users:(("rpcbind",pid=499,fd=6),("systemd",pid=1,fd=124))
tcp   LISTEN 0      1024             [::]:80            [::]:*    users:(("lighttpd",pid=9535,fd=5))
tcp   LISTEN 0      4096                *:81               *:*    users:(("casaos-gateway",pid=980,fd=8))
tcp   LISTEN 0      4096                *:8083             *:*    users:(("AdGuardHome",pid=9660,fd=9))
tcp   LISTEN 0      4096                *:53               *:*    users:(("AdGuardHome",pid=9660,fd=12))
tcp   LISTEN 0      128              [::]:51413         [::]:*    users:(("transmission-da",pid=9547,fd=16))
tcp   LISTEN 0      1000             [::]:22            [::]:*    users:(("dropbear",pid=705,fd=5))
tcp   LISTEN 0      4096             [::]:3000          [::]:*    users:(("docker-proxy",pid=9846,fd=4))
tcp   LISTEN 0      4096             [::]:3001          [::]:*    users:(("docker-proxy",pid=9823,fd=4))
tcp   LISTEN 0      50               [::]:445           [::]:*    users:(("smbd",pid=9358,fd=46))

But still not working the dns

Joulinar · 15 December 2022 09:29

ok as next step, let’s try to catch what unbound is doing while trying to resolve DNS request. I have the feeling, it’s going into direction of blocked DNSSEC request Unbound not working with pi-hole

First, we need the tcpdump tool to be installed

apt install tcpdump

Stop AGH

systemctl stop adguardhome

Once done start tcpdump on 1st SSH session

tcpdump -i any -c500 -nn port 53 or port 5335

On a 2nd SSH session, perform a test

dig @127.0.0.1 -p 5335 google.com

Stop/cancel tcpdump and restart AGH

pietromezza · 15 December 2022 09:35

root@DietPi:~# tcpdump -i any -c500 -nn port 53 or port 5335
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:34:34.100432 lo    In  IP 127.0.0.1.55692 > 127.0.0.1.5335: UDP, length 51
10:34:34.100880 eth0  Out IP 192.168.1.35.54815 > 193.0.14.129.53: 42699% [1au] NS? . (28)
10:34:34.104465 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.54815: 42699 ServFail* 0/0/1 (28)
10:34:34.104709 eth0  Out IP 192.168.1.35.47395 > 192.33.4.12.53: 40308% [1au] NS? . (28)
10:34:34.107223 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.47395: 40308 ServFail* 0/0/1 (28)
10:34:34.107404 eth0  Out IP 192.168.1.35.32621 > 199.9.14.201.53: 20021% [1au] NS? . (28)
10:34:34.109857 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.32621: 20021 ServFail* 0/0/1 (28)
10:34:34.110097 eth0  Out IP 192.168.1.35.39284 > 192.112.36.4.53: 26951% [1au] NS? . (28)
10:34:34.113314 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.39284: 26951 ServFail* 0/0/1 (28)
10:34:34.113600 eth0  Out IP 192.168.1.35.29525 > 202.12.27.33.53: 23935% [1au] NS? . (28)
10:34:34.115441 eth0  In  IP 202.12.27.33.53 > 192.168.1.35.29525: 23935 ServFail* 0/0/1 (28)
10:34:34.115696 eth0  Out IP 192.168.1.35.54087 > 192.58.128.30.53: 15641% [1au] NS? . (28)
10:34:34.116807 eth0  In  IP 192.58.128.30.53 > 192.168.1.35.54087: 15641 ServFail* 0/0/1 (28)
10:34:34.117043 eth0  Out IP 192.168.1.35.34509 > 192.33.4.12.53: 64550% [1au] NS? . (28)
10:34:34.118027 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.34509: 64550 ServFail* 0/0/1 (28)
10:34:34.118278 eth0  Out IP 192.168.1.35.48146 > 198.41.0.4.53: 13802% [1au] NS? . (28)
10:34:34.119298 eth0  In  IP 198.41.0.4.53 > 192.168.1.35.48146: 13802 ServFail* 0/0/1 (28)
10:34:34.119759 eth0  Out IP 192.168.1.35.29005 > 192.112.36.4.53: 29583% [1au] NS? . (28)
10:34:34.120767 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.29005: 29583 ServFail* 0/0/1 (28)
10:34:34.121315 eth0  Out IP 192.168.1.35.47391 > 199.7.83.42.53: 35465% [1au] NS? . (28)
10:34:34.122853 eth0  In  IP 199.7.83.42.53 > 192.168.1.35.47391: 35465 ServFail* 0/0/1 (28)
10:34:34.123209 eth0  Out IP 192.168.1.35.22506 > 192.112.36.4.53: 31858% [1au] NS? . (28)
10:34:34.124202 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.22506: 31858 ServFail* 0/0/1 (28)
10:34:34.124507 eth0  Out IP 192.168.1.35.49984 > 192.33.4.12.53: 61119% [1au] NS? . (28)
10:34:34.125529 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.49984: 61119 ServFail* 0/0/1 (28)
10:34:34.125805 eth0  Out IP 192.168.1.35.36137 > 193.0.14.129.53: 47110% [1au] NS? . (28)
10:34:34.126764 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.36137: 47110 ServFail* 0/0/1 (28)
10:34:34.127268 eth0  Out IP 192.168.1.35.41660 > 192.33.4.12.53: 39797% [1au] NS? . (28)
10:34:34.128261 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.41660: 39797 ServFail* 0/0/1 (28)
10:34:34.128605 eth0  Out IP 192.168.1.35.20923 > 193.0.14.129.53: 31123% [1au] NS? . (28)
10:34:34.129540 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.20923: 31123 ServFail* 0/0/1 (28)
10:34:34.129828 eth0  Out IP 192.168.1.35.42168 > 199.9.14.201.53: 30071% [1au] NS? . (28)
10:34:34.130777 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.42168: 30071 ServFail* 0/0/1 (28)
10:34:34.131535 eth0  Out IP 192.168.1.35.20317 > 199.9.14.201.53: 10363% [1au] NS? . (28)
10:34:34.132611 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.20317: 10363 ServFail* 0/0/1 (28)
10:34:34.133071 eth0  Out IP 192.168.1.35.31288 > 198.41.0.4.53: 61416% [1au] NS? . (28)
10:34:34.134056 eth0  In  IP 198.41.0.4.53 > 192.168.1.35.31288: 61416 ServFail* 0/0/1 (28)
10:34:34.134438 eth0  Out IP 192.168.1.35.25950 > 192.5.5.241.53: 54388% [1au] NS? . (28)
10:34:34.135303 eth0  In  IP 192.5.5.241.53 > 192.168.1.35.25950: 54388 ServFail* 0/0/1 (28)
10:34:34.135830 eth0  Out IP 192.168.1.35.31751 > 193.0.14.129.53: 29101% [1au] NS? . (28)
10:34:34.136624 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.31751: 29101 ServFail* 0/0/1 (28)
10:34:34.137158 eth0  Out IP 192.168.1.35.43414 > 199.9.14.201.53: 59521% [1au] NS? . (28)
10:34:34.137966 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.43414: 59521 ServFail* 0/0/1 (28)
10:34:34.138534 eth0  Out IP 192.168.1.35.21893 > 199.7.83.42.53: 49214% [1au] NS? . (28)
10:34:34.139351 eth0  In  IP 199.7.83.42.53 > 192.168.1.35.21893: 49214 ServFail* 0/0/1 (28)
10:34:34.139844 eth0  Out IP 192.168.1.35.7583 > 202.12.27.33.53: 54544% [1au] NS? . (28)
10:34:34.140662 eth0  In  IP 202.12.27.33.53 > 192.168.1.35.7583: 54544 ServFail* 0/0/1 (28)
10:34:34.141195 eth0  Out IP 192.168.1.35.42399 > 192.33.4.12.53: 51442% [1au] NS? . (28)
10:34:34.141975 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.42399: 51442 ServFail* 0/0/1 (28)
10:34:34.142488 eth0  Out IP 192.168.1.35.62654 > 192.203.230.10.53: 27580% [1au] NS? . (28)
10:34:34.143353 eth0  In  IP 192.203.230.10.53 > 192.168.1.35.62654: 27580 ServFail* 0/0/1 (28)
10:34:34.143884 eth0  Out IP 192.168.1.35.20643 > 199.7.91.13.53: 53923% [1au] NS? . (28)
10:34:34.144673 eth0  In  IP 199.7.91.13.53 > 192.168.1.35.20643: 53923 ServFail* 0/0/1 (28)
10:34:34.145182 eth0  Out IP 192.168.1.35.44953 > 199.9.14.201.53: 46190% [1au] NS? . (28)
10:34:34.145957 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.44953: 46190 ServFail* 0/0/1 (28)
10:34:34.146440 eth0  Out IP 192.168.1.35.31682 > 192.5.5.241.53: 63475% [1au] NS? . (28)
10:34:34.147220 eth0  In  IP 192.5.5.241.53 > 192.168.1.35.31682: 63475 ServFail* 0/0/1 (28)
10:34:34.147733 eth0  Out IP 192.168.1.35.53510 > 199.7.91.13.53: 3629% [1au] NS? . (28)
10:34:34.148534 eth0  In  IP 199.7.91.13.53 > 192.168.1.35.53510: 3629 ServFail* 0/0/1 (28)
10:34:34.149022 eth0  Out IP 192.168.1.35.60850 > 198.97.190.53.53: 54942% [1au] NS? . (28)
10:34:34.149781 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.60850: 54942 ServFail* 0/0/1 (28)
10:34:34.150267 eth0  Out IP 192.168.1.35.38638 > 198.97.190.53.53: 61518% [1au] NS? . (28)
10:34:34.151167 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.38638: 61518 ServFail* 0/0/1 (28)
10:34:34.151734 eth0  Out IP 192.168.1.35.61204 > 192.112.36.4.53: 1313% [1au] NS? . (28)
10:34:34.152564 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.61204: 1313 ServFail* 0/0/1 (28)
10:34:34.153074 eth0  Out IP 192.168.1.35.43933 > 192.36.148.17.53: 39980% [1au] NS? . (28)
10:34:34.153922 eth0  In  IP 192.36.148.17.53 > 192.168.1.35.43933: 39980 ServFail* 0/0/1 (28)
10:34:34.154241 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.55692: UDP, length 39
10:35:01.807468 eth0  Out IP 192.168.1.35.56378 > 192.168.1.1.53: 40068+ A? www.duckdns.org. (33)
10:35:01.807511 eth0  Out IP 192.168.1.35.56378 > 192.168.1.1.53: 3251+ AAAA? www.duckdns.org. (33)
10:35:01.820043 eth0  In  IP 192.168.1.1.53 > 192.168.1.35.56378: 40068 4/0/0 CNAME appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com., A 3.98.106.130, A 99.79.132.39, A 3.97.227.96 (160)
10:35:01.820474 eth0  In  IP 192.168.1.1.53 > 192.168.1.35.56378: 3251 1/1/0 CNAME appservers-duckdns-prod-1630339571.ca-central-1.elb.amazonaws.com. (193)
10:35:03.475898 veth735c9f0 P   IP 172.17.0.2.42986 > 1.1.1.1.53: 53326+ A? giggino99.duckdns.org. (39)
10:35:03.475976 docker0 In  IP 172.17.0.2.42986 > 1.1.1.1.53: 53326+ A? giggino99.duckdns.org. (39)
10:35:03.476067 eth0  Out IP 192.168.1.35.42986 > 1.1.1.1.53: 53326+ A? giggino99.duckdns.org. (39)
10:35:03.506387 veth735c9f0 P   IP 172.17.0.2.44952 > 192.168.1.1.53: 43502+ A? www.iliad.it. (30)
10:35:03.506496 docker0 In  IP 172.17.0.2.44952 > 192.168.1.1.53: 43502+ A? www.iliad.it. (30)
10:35:03.506622 eth0  Out IP 192.168.1.35.44952 > 192.168.1.1.53: 43502+ A? www.iliad.it. (30)
10:35:03.509597 eth0  In  IP 192.168.1.1.53 > 192.168.1.35.44952: 43502 1/0/0 A 83.158.240.200 (46)
10:35:03.509739 docker0 Out IP 192.168.1.1.53 > 172.17.0.2.44952: 43502 1/0/0 A 83.158.240.200 (46)
10:35:03.509773 veth735c9f0 Out IP 192.168.1.1.53 > 172.17.0.2.44952: 43502 1/0/0 A 83.158.240.200 (46)
10:35:03.590446 eth0  In  IP 1.1.1.1.53 > 192.168.1.35.42986: 53326 1/0/0 A 2.34.225.173 (55)
10:35:03.590569 docker0 Out IP 1.1.1.1.53 > 172.17.0.2.42986: 53326 1/0/0 A 2.34.225.173 (55)
10:35:03.590599 veth735c9f0 Out IP 1.1.1.1.53 > 172.17.0.2.42986: 53326 1/0/0 A 2.34.225.173 (55)
10:35:06.844178 eth0  Out IP 192.168.1.35.45569 > 192.168.1.1.53: 42462+ PTR? 2.1.168.192.in-addr.arpa. (42)
10:35:06.844817 lo    In  IP 127.0.0.1.43408 > 127.0.0.1.5335: UDP, length 50
10:35:06.844817 lo    In  IP 127.0.0.1.55082 > 127.0.0.1.5335: UDP, length 50
10:35:06.845414 eth0  Out IP 192.168.1.35.14915 > 192.36.148.17.53: 34583% [1au] NS? . (28)
10:35:06.847684 eth0  In  IP 192.168.1.1.53 > 192.168.1.35.45569: 42462* 1/0/0 PTR Raspy.station. (69)
10:35:06.851727 eth0  In  IP 192.36.148.17.53 > 192.168.1.35.14915: 34583 ServFail* 0/0/1 (28)
10:35:06.852132 eth0  Out IP 192.168.1.35.39380 > 199.7.83.42.53: 35349% [1au] NS? . (28)
10:35:06.855598 eth0  In  IP 199.7.83.42.53 > 192.168.1.35.39380: 35349 ServFail* 0/0/1 (28)
10:35:06.855920 eth0  Out IP 192.168.1.35.29509 > 198.97.190.53.53: 10836% [1au] NS? . (28)
10:35:06.858600 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.29509: 10836 ServFail* 0/0/1 (28)
10:35:06.858846 eth0  Out IP 192.168.1.35.17055 > 192.33.4.12.53: 6653% [1au] NS? . (28)
10:35:06.861435 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.17055: 6653 ServFail* 0/0/1 (28)
10:35:06.861685 eth0  Out IP 192.168.1.35.23340 > 192.33.4.12.53: 7519% [1au] NS? . (28)
10:35:06.863200 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.23340: 7519 ServFail* 0/0/1 (28)
10:35:06.863564 eth0  Out IP 192.168.1.35.37000 > 193.0.14.129.53: 57798% [1au] NS? . (28)
10:35:06.864488 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.37000: 57798 ServFail* 0/0/1 (28)
10:35:06.864849 eth0  Out IP 192.168.1.35.28354 > 198.41.0.4.53: 22555% [1au] NS? . (28)
10:35:06.865685 eth0  In  IP 198.41.0.4.53 > 192.168.1.35.28354: 22555 ServFail* 0/0/1 (28)
10:35:06.866023 eth0  Out IP 192.168.1.35.51597 > 192.112.36.4.53: 40870% [1au] NS? . (28)
10:35:06.866811 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.51597: 40870 ServFail* 0/0/1 (28)
10:35:06.867190 eth0  Out IP 192.168.1.35.19002 > 199.7.91.13.53: 11213% [1au] NS? . (28)
10:35:06.868852 eth0  In  IP 199.7.91.13.53 > 192.168.1.35.19002: 11213 ServFail* 0/0/1 (28)
10:35:06.869178 eth0  Out IP 192.168.1.35.57408 > 199.9.14.201.53: 39432% [1au] NS? . (28)
10:35:06.870608 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.57408: 39432 ServFail* 0/0/1 (28)
10:35:06.870970 eth0  Out IP 192.168.1.35.50742 > 199.9.14.201.53: 1000% [1au] NS? . (28)
10:35:06.872421 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.50742: 1000 ServFail* 0/0/1 (28)
10:35:06.872780 eth0  Out IP 192.168.1.35.49145 > 199.7.91.13.53: 46556% [1au] NS? . (28)
10:35:06.874110 eth0  In  IP 199.7.91.13.53 > 192.168.1.35.49145: 46556 ServFail* 0/0/1 (28)
10:35:06.874437 eth0  Out IP 192.168.1.35.37248 > 192.5.5.241.53: 14988% [1au] NS? . (28)
10:35:06.875492 eth0  In  IP 192.5.5.241.53 > 192.168.1.35.37248: 14988 ServFail* 0/0/1 (28)
10:35:06.875822 eth0  Out IP 192.168.1.35.50324 > 192.58.128.30.53: 61196% [1au] NS? . (28)
10:35:06.876832 eth0  In  IP 192.58.128.30.53 > 192.168.1.35.50324: 61196 ServFail* 0/0/1 (28)
10:35:06.877155 eth0  Out IP 192.168.1.35.29591 > 198.97.190.53.53: 57190% [1au] NS? . (28)
10:35:06.878122 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.29591: 57190 ServFail* 0/0/1 (28)
10:35:06.878459 eth0  Out IP 192.168.1.35.22873 > 199.9.14.201.53: 41700% [1au] NS? . (28)
10:35:06.879358 eth0  In  IP 199.9.14.201.53 > 192.168.1.35.22873: 41700 ServFail* 0/0/1 (28)
10:35:06.879709 eth0  Out IP 192.168.1.35.38271 > 192.5.5.241.53: 61991% [1au] NS? . (28)
10:35:06.885457 eth0  In  IP 192.5.5.241.53 > 192.168.1.35.38271: 61991 ServFail* 0/0/1 (28)
10:35:06.885784 eth0  Out IP 192.168.1.35.11719 > 192.203.230.10.53: 60170% [1au] NS? . (28)
10:35:06.886823 eth0  In  IP 192.203.230.10.53 > 192.168.1.35.11719: 60170 ServFail* 0/0/1 (28)
10:35:06.887194 eth0  Out IP 192.168.1.35.35668 > 202.12.27.33.53: 20754% [1au] NS? . (28)
10:35:06.888029 eth0  In  IP 202.12.27.33.53 > 192.168.1.35.35668: 20754 ServFail* 0/0/1 (28)
10:35:06.888376 eth0  Out IP 192.168.1.35.4624 > 192.203.230.10.53: 872% [1au] NS? . (28)
10:35:06.889163 eth0  In  IP 192.203.230.10.53 > 192.168.1.35.4624: 872 ServFail* 0/0/1 (28)
10:35:06.889505 eth0  Out IP 192.168.1.35.35664 > 193.0.14.129.53: 20204% [1au] NS? . (28)
10:35:06.890282 eth0  In  IP 193.0.14.129.53 > 192.168.1.35.35664: 20204 ServFail* 0/0/1 (28)
10:35:06.890619 eth0  Out IP 192.168.1.35.12613 > 198.97.190.53.53: 4761% [1au] NS? . (28)
10:35:06.891437 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.12613: 4761 ServFail* 0/0/1 (28)
10:35:06.892062 eth0  Out IP 192.168.1.35.14932 > 199.7.91.13.53: 14402% [1au] NS? . (28)
10:35:06.893384 eth0  In  IP 199.7.91.13.53 > 192.168.1.35.14932: 14402 ServFail* 0/0/1 (28)
10:35:06.894056 eth0  Out IP 192.168.1.35.43568 > 192.33.4.12.53: 16718% [1au] NS? . (28)
10:35:06.895099 eth0  In  IP 192.33.4.12.53 > 192.168.1.35.43568: 16718 ServFail* 0/0/1 (28)
10:35:06.895857 eth0  Out IP 192.168.1.35.35147 > 198.97.190.53.53: 17786% [1au] NS? . (28)
10:35:06.896883 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.35147: 17786 ServFail* 0/0/1 (28)
10:35:06.897643 eth0  Out IP 192.168.1.35.14512 > 192.58.128.30.53: 41775% [1au] NS? . (28)
10:35:06.898572 eth0  In  IP 192.58.128.30.53 > 192.168.1.35.14512: 41775 ServFail* 0/0/1 (28)
10:35:06.899328 eth0  Out IP 192.168.1.35.23338 > 192.58.128.30.53: 22463% [1au] NS? . (28)
10:35:06.900154 eth0  In  IP 192.58.128.30.53 > 192.168.1.35.23338: 22463 ServFail* 0/0/1 (28)
10:35:06.901001 eth0  Out IP 192.168.1.35.50497 > 199.7.83.42.53: 45965% [1au] NS? . (28)
10:35:06.901846 eth0  In  IP 199.7.83.42.53 > 192.168.1.35.50497: 45965 ServFail* 0/0/1 (28)
10:35:06.902505 eth0  Out IP 192.168.1.35.13900 > 198.97.190.53.53: 17141% [1au] NS? . (28)
10:35:06.903427 eth0  In  IP 198.97.190.53.53 > 192.168.1.35.13900: 17141 ServFail* 0/0/1 (28)
10:35:06.904110 eth0  Out IP 192.168.1.35.62188 > 202.12.27.33.53: 50491% [1au] NS? . (28)
10:35:06.904950 eth0  In  IP 202.12.27.33.53 > 192.168.1.35.62188: 50491 ServFail* 0/0/1 (28)
10:35:06.905778 eth0  Out IP 192.168.1.35.29019 > 192.112.36.4.53: 50225% [1au] NS? . (28)
10:35:06.906610 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.29019: 50225 ServFail* 0/0/1 (28)
10:35:06.907642 eth0  Out IP 192.168.1.35.64544 > 199.7.83.42.53: 14060% [1au] NS? . (28)
10:35:06.908469 eth0  In  IP 199.7.83.42.53 > 192.168.1.35.64544: 14060 ServFail* 0/0/1 (28)
10:35:06.909036 eth0  Out IP 192.168.1.35.32905 > 192.112.36.4.53: 41586% [1au] NS? . (28)
10:35:06.909803 eth0  In  IP 192.112.36.4.53 > 192.168.1.35.32905: 41586 ServFail* 0/0/1 (28)
10:35:06.910120 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.55082: UDP, length 50
10:35:06.910279 lo    In  IP 127.0.0.1.5335 > 127.0.0.1.43408: UDP, length 50
^C
156 packets captured
163 packets received by filter
0 packets dropped by kernel

Joulinar · 15 December 2022 10:12

are you able to resolve request directly with one of the root DNS server?

dig @192.33.4.12 google.com

pietromezza · 15 December 2022 10:17

root@DietPi:~# dig @192.33.4.12 google.com

; <<>> DiG 9.16.33-Debian <<>> @192.33.4.12 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17510
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 15c90fffaa37f7fc5f4bf26b639af42b3896bcd7b13a41fb (good)
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             215     IN      A       142.250.180.174

;; Query time: 12 msec
;; SERVER: 192.33.4.12#53(192.33.4.12)
;; WHEN: Thu Dec 15 11:17:15 CET 2022
;; MSG SIZE  rcvd: 83

Joulinar · 15 December 2022 10:26

ok that seems to be working fine. For testing we could try to disable DNSSEC

mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.bak
systemctl restart unbound
dig @127.0.0.1 -p 5335 google.com

pietromezza · 15 December 2022 10:29

root@DietPi:~# mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.bak
root@DietPi:~# systemctl restart unbound
root@DietPi:~# dig @127.0.0.1 -p 5335 google.com

; <<>> DiG 9.16.33-Debian <<>> @127.0.0.1 -p 5335 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43880
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 36 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Thu Dec 15 11:28:37 CET 2022
;; MSG SIZE  rcvd: 39

root@DietPi:~#

Joulinar · 15 December 2022 10:43

sorry for digging around but I’m still not sure why Unbound has issues to connect to root DNS servers.

Let’s try to increase debug level to the highest level 5.

G_CONFIG_INJECT '        verbosity:' '        verbosity:5' /etc/unbound/unbound.conf.d/dietpi.conf

Reboot and check logs again

dig @127.0.0.1 -p 5335 google.com
journalctl -u unbound.service

pietromezza · 15 December 2022 10:55

Look, you’re giving me crazy assistance and with very fast times, so I’m happy

if u need more log tell me
I had to cut them because there were too many

logs_unbound.txt (1.3 MB)

Joulinar · 15 December 2022 11:19

still strange, do you use some special firewall or other network security? There is some communication between unbount and root DNS server, however response seems to be empty

Dec 15 11:48:17 DietPi unbound[856]: [856:0] debug: sending to target: <.> 192.112.36.4#53
...
Dec 15 11:48:17 DietPi unbound[856]: [856:0] debug: Incoming reply addr = ip4 192.112.36.4 port 53 (len 16)
..
Dec 15 11:48:17 DietPi unbound[856]: [856:0] info: reply from <.> 192.112.36.4#53
Dec 15 11:48:17 DietPi unbound[856]: [856:0] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 0
                                     ;; flags: qr aa ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
                                     ;; QUESTION SECTION:
                                     .        IN        NS

                                     ;; ANSWER SECTION:

                                     ;; AUTHORITY SECTION:

                                     ;; ADDITIONAL SECTION:
                                     ;; MSG SIZE  rcvd: 17
Dec 15 11:48:17 DietPi unbound[856]: [856:0] debug: iter_handle processing q with state QUERY RESPONSE STATE
Dec 15 11:48:17 DietPi unbound[856]: [856:0] info: query response was THROWAWAY

For testing, we could try to adjust DNS forward zone to point to Cloudflare and Quad9. Let’s see if this might be working.

cat << '_EOF_' > /etc/unbound/unbound.conf.d/dietpi-forward.conf
# Adding own forward-zone
forward-zone:
name: "."
## Cloudflare
forward-addr: 1.1.1.1@53#cloudflare-dns.com
forward-addr: 1.0.0.1@53#cloudflare-dns.com
## Quad9
forward-addr: 9.9.9.9@53#dns.quad9.net
forward-addr: 149.112.112.112@53#dns.quad9.net
_EOF_

reboot the system

dig @127.0.0.1 -p 5335 google.com

pietromezza · 15 December 2022 11:27

I went to see the router settings and indeed there is a firewall

see photo :
https://ibb.co/m4HGNLC

root@DietPi:~# dig @127.0.0.1 -p 5335 google.com

; <<>> DiG 9.16.33-Debian <<>> @127.0.0.1 -p 5335 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40100
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
google.com.             300     IN      A       142.250.180.174

;; Query time: 24 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Thu Dec 15 12:26:36 CET 2022
;; MSG SIZE  rcvd: 55

root@DietPi:~#

Joulinar · 15 December 2022 12:20

that’s the normal firewall such router has. Usually, they should not block DNS request. OK it’s a Vodafone box, who knows

OK, using Cloudflare and Quad9 seems to be working fine according dig. But this is not the aim if having unbound installed. Usually, you like to use root DNS server instead of a public upstream one

Let’s try to revert some steps we did for testing

mv /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.bak /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf
G_CONFIG_INJECT '        verbosity:' '        verbosity:0' /etc/unbound/unbound.conf.d/dietpi.conf
systemctl restart unbound
dig @127.0.0.1 -p 5335 google.com

Is dig still working?

pietromezza · 15 December 2022 13:00

root@DietPi:~# dig @127.0.0.1 -p 5335 google.com

; <<>> DiG 9.16.33-Debian <<>> @127.0.0.1 -p 5335 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51350
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 200 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Thu Dec 15 13:59:03 CET 2022
;; MSG SIZE  rcvd: 39

root@DietPi:~#

i try to uncheck the firewall?

Joulinar · 15 December 2022 13:14

try for testing only and set it back after your finished.

Btw: do you have a wifi module for the ROCKPro64? If yes, we would test with a hotspot created by a mobile device. Just to exclude internet connection or router.