# Adguard + Unbuond Configuration ISSUE **URL:** \ **Category:** Troubleshooting\ **Created:** [15 December 2022 00:14 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246 "2022-12-15T00:14:47Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 00:14 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/1 "2022-12-15T00:14:47Z")
### 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 : ```auto 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. ``` * * * ```auto 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 ``` * * * ```auto 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 ---
**Author:** ![Jappe](https://dietpi.com/forum/user_avatar/dietpi.com/jappe/32/1788_2.png) [@Jappe](https://dietpi.com/forum/u/Jappe)\ **Post date:** [15 December 2022 00:36 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/2 "2022-12-15T00:36:14Z")
Is this the whole output from `ss -tulpn | grep LISTEN`? If yes, then unbound is not listening at all. Can you do: ```auto 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://\:8083 ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 07:38 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/3 "2022-12-15T07:38:25Z")
> [@pietromezza](#): > > 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” 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. > [@Jappe](#): > > Is this the whole output from `ss -tulpn | grep LISTEN`? doubt this was the whole output. Otherwise SSH server would be missing 😉 Usually it should looks like this ```auto 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](#): > > ```auto > 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? ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 08:36 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/4 "2022-12-15T08:36:02Z")
Thx Jappe for responding Adguard works fine without unbound Tell me what else I could do to help you better thanks ```auto 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 ``` ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 08:46 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/5 "2022-12-15T08:46:03Z")
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 : ```auto 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 ```auto 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 ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 08:53 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/6 "2022-12-15T08:53:56Z")
> [@pietromezza](#): > > ```auto > 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 ```auto s -tulpn | grep LISTEN ``` My guess, unbound has issues to connect to root DNS server. Somethig we could verify after reboot. ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 09:00 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/7 "2022-12-15T09:00:02Z")
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 ☹ ```auto 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 ```auto 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 ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 09:29 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/8 "2022-12-15T09:29:05Z")
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](https://dietpi.com/forum/t/unbound-not-working-with-pi-hole/14431) First, we need the `tcpdump` tool to be installed ```auto apt install tcpdump ``` Stop AGH ```auto systemctl stop adguardhome ``` Once done start `tcpdump` on 1st SSH session ```auto tcpdump -i any -c500 -nn port 53 or port 5335 ``` On a 2nd SSH session, perform a test ```auto dig @127.0.0.1 -p 5335 google.com ``` Stop/cancel `tcpdump` and restart AGH ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 09:35 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/9 "2022-12-15T09:35:55Z")
> [@Joulinar](#): > > `adguardhome` ```auto 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 ``` ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 10:12 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/10 "2022-12-15T10:12:05Z")
are you able to resolve request directly with one of the root DNS server? ```auto dig @192.33.4.12 google.com ``` ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 10:17 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/11 "2022-12-15T10:17:33Z")
```auto 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 ``` ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 10:26 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/12 "2022-12-15T10:26:18Z")
ok that seems to be working fine. For testing we could try to disable DNSSEC ```auto 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 ``` ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 10:29 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/13 "2022-12-15T10:29:20Z")
> [@Joulinar](#): > > `dig @127.0.0.1 -p 5335 google.com` ```auto 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:~# ``` ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 10:43 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/14 "2022-12-15T10:43:12Z")
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. ```auto G_CONFIG_INJECT ' verbosity:' ' verbosity:5' /etc/unbound/unbound.conf.d/dietpi.conf ``` Reboot and check logs again ```auto dig @127.0.0.1 -p 5335 google.com journalctl -u unbound.service ``` ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 10:55 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/15 "2022-12-15T10:55:33Z")
> [@Joulinar](#): > > `journalctl -u unbound.service` 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](https://dietpi.com/forum/uploads/short-url/9VhsMBf8a4VRvUeushkaLyl1p1u.txt) (1.3 MB) ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 11:19 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/16 "2022-12-15T11:19:32Z")
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 ```auto 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. ```auto 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 ```auto dig @127.0.0.1 -p 5335 google.com ``` ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 11:27 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/17 "2022-12-15T11:27:18Z")
> [@Joulinar](#): > > `dig @127.0.0.1 -p 5335 google.com` I went to see the router settings and indeed there is a firewall see photo : [https://ibb.co/m4HGNLC](https://ibb.co/m4HGNLC) ```auto 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:~# ``` ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 12:20 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/18 "2022-12-15T12:20:47Z")
that’s the normal firewall such router has. Usually, they should not block DNS request. OK it’s a Vodafone box, who knows 🤣 > [@pietromezza](#): > > ```auto > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40100 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ``` 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 ```auto 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? ---
**Author:** ![pietromezza](https://dietpi.com/forum/user_avatar/dietpi.com/pietromezza/32/2654_2.png) [@pietromezza](https://dietpi.com/forum/u/pietromezza)\ **Post date:** [15 December 2022 13:00 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/19 "2022-12-15T13:00:17Z")
> [@Joulinar](#): > > `dig @127.0.0.1 -p 5335 google.com` ```auto 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? ---
**Author:** ![Joulinar](https://dietpi.com/forum/user_avatar/dietpi.com/joulinar/32/57_2.png) [@Joulinar](https://dietpi.com/forum/u/Joulinar)\ **Post date:** [15 December 2022 13:14 UTC](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246/20 "2022-12-15T13:14:58Z")
> [@pietromezza](#): > > i try to uncheck the firewall? 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. [Next page](https://dietpi.com/forum/t/adguard-unbuond-configuration-issue/15246.md?page=2)