MatthewVance
commented
2 years ago Hi, no bother. The issue is because Ubuntu comes with systemd-resolved by default that used port 53 on your host. You’ll need to disable that or run the Unbound container on a different port.
On Mar 10, 2022, at 8:11 PM, AliSot2000 @.***> wrote:
Hi I'm sorry to bother you but this seems to be the most suitable place to ask this question.
I have a Raspberry Pi with ubuntu-server 20.04.04 LTS. I'd like to have an unbound image running in on my pi. As I would like to be able to access the server from within the network and not only a pi-hole, which is also running on said rpi, I'm using it in a little bit different way.
I have created a IPv4 docker network to which both the pi-hole as well as the unbound server are connected (a Nextcloud is also using the same network if this is of concern)
I modified the config which is provided by the pi-hole install guide slightly to make it "suitable" for my needs. (I suspect an issue might lay here).
Anyway. I tried to start the container (just to be sure) with your recommended command on in the ReadMe.
docker run \ --name=unbound-rpi \ --publish=53:53/udp \ --publish=53:53/tcp \ --restart=unless-stopped \ --detach=true \ mvance/unbound-rpi:latest However I got the following response:
docker: Error response from daemon: driver failed programming external connectivity on endpoint unbound-rpi(ea60e7bf49b2a97ab0070e7bff1eee0bf67818715371d520ef3fc6871c64a4b2): Error starting userland proxy: listen tcp4 0.0.0.0:53: bind: address already in use. It might have something to do with:
systemd-r 686 systemd-resolve 12u IPv4 21828 0t0 UDP 127.0.0.53:53 systemd-r 686 systemd-resolve 13u IPv4 21829 0t0 TCP 127.0.0.53:53 (LISTEN) I would like to use this modified unbound.conf:
server:
If no logfile is specified, syslog is used
logfile: "/opt/unbound/etc/unbound/unbound.log" verbosity: 4 interface: 192.168.1.43 # interface: 0.0.0.0/24 <- this was a test, didn't work either. port: 53 do-ip4: yes do-udp: yes do-tcp: yes # May be set to yes if you have IPv6 connectivity do-ip6: no # You want to leave this to no unless you have *native* IPv6. With 6to4 and # Terredo tunnels your web browser should favor IPv4 for the same reasons prefer-ip6: no # Use this only when you downloaded the list of primary root servers! # If you use the default dns-root-data package, unbound will find it automatically #root-hints: "/var/lib/unbound/root.hints" # Trust glue only if it is within the server's authority harden-glue: yes # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS harden-dnssec-stripped: yes # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details use-caps-for-id: no # Reduce EDNS reassembly buffer size. # IP fragmentation is unreliable on the Internet today, and can cause # transmission failures when large DNS messages are sent via UDP. Even # when fragmentation does work, it may not be secure; it is theoretically # possible to spoof parts of a fragmented DNS message, without easy # detection at the receiving end. Recently, there was an excellent study # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<< # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/) # in collaboration with NLnet Labs explored DNS using real world data from the # the RIPE Atlas probes and the researchers suggested different values for # IPv4 and IPv6 and in different scenarios. They advise that servers should # be configured to limit DNS messages sent over UDP to a size that will not # trigger fragmentation on typical network links. DNS servers can switch # from UDP to TCP when a DNS response is too big to fit in this limited # buffer size. This value has also been suggested in DNS Flag Day 2020. edns-buffer-size: 1232 # Perform prefetching of close to expired message cache entries # This only applies to domains that have been frequently queried prefetch: yes # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1. num-threads: 1 # Ensure kernel buffer is large enough to not lose messages in traffic spikes so-rcvbuf: 1m # Ensure privacy of local IP ranges private-address: 192.168.0.0/16 private-address: 169.254.0.0/16 private-address: 172.16.0.0/12 private-address: 10.0.0.0/8Which is as I mentioned a modified version from this: Pi-Hole-Docs
While starting, the container is healthy but as soon as it is running, it becomes unhealthy. I tried several times with different configs and debug levels but it always stays the same; the server refuses the queries.
Here are the logs on verbosity 4: (I created the container with the following start command and this is everything after it has been running) docker run -d --network=dockernet --ip=192.168.1.43 --name=unbound -v=/mnt/SSD/docker_external_volumes/unbound/:/opt/unbound/etc/unbound --restart=unless-stopped mvance/unbound-rpi:latest
[1646962928] unbound[1:0] debug: module config: "validator iterator" [1646962928] unbound[1:0] notice: init module 0: validator [1646962928] unbound[1:0] debug: validator nsec3cfg keysz 1024 mxiter 150 [1646962928] unbound[1:0] debug: validator nsec3cfg keysz 2048 mxiter 150 [1646962928] unbound[1:0] debug: validator nsec3cfg keysz 4096 mxiter 150 [1646962928] unbound[1:0] notice: init module 1: iterator [1646962928] unbound[1:0] debug: target fetch policy for level 0 is 3 [1646962928] unbound[1:0] debug: target fetch policy for level 1 is 2 [1646962928] unbound[1:0] debug: target fetch policy for level 2 is 1 [1646962928] unbound[1:0] debug: target fetch policy for level 3 is 0 [1646962928] unbound[1:0] debug: target fetch policy for level 4 is 0 [1646962928] unbound[1:0] debug: donotq: 127.0.0.0/8 [1646962928] unbound[1:0] debug: total of 59459 outgoing ports available [1646962928] unbound[1:0] debug: start threads [1646962928] unbound[1:0] debug: libevent 2.1.12-stable uses epoll method. [1646962928] unbound[1:0] debug: no config, using builtin root hints. [1646962928] unbound[1:0] debug: cache memory msg=33040 rrset=33040 infra=3920 val=33200 [1646962928] unbound[1:0] info: start of service (unbound 1.15.0). [1646962930] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54391 (len 16) [1646962930] unbound[1:0] debug: refuse[30:0] 1E8501000001000000000000046D61696C046574687A0263680000410001 [1646962930] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56525 (len 16) [1646962930] unbound[1:0] debug: refuse[30:0] 599F01000001000000000000046D61696C046574687A02636800001C0001 [1646962930] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 61711 (len 16) [1646962930] unbound[1:0] debug: refuse[30:0] 78F601000001000000000000046D61696C046574687A0263680000010001 [1646962931] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54391 (len 16) [1646962931] unbound[1:0] debug: refuse[30:0] 1E8501000001000000000000046D61696C046574687A0263680000410001 [1646962931] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56525 (len 16) [1646962931] unbound[1:0] debug: refuse[30:0] 599F01000001000000000000046D61696C046574687A02636800001C0001 [1646962931] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 61711 (len 16) [1646962931] unbound[1:0] debug: refuse[30:0] 78F601000001000000000000046D61696C046574687A0263680000010001 [1646963201] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 63744 (len 16) [1646963201] unbound[1:0] debug: refuse[42:0] 384E010000010000000000000767617465776179026665096170706C652D646E73036E65740000410001 [1646963201] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 63616 (len 16) [1646963201] unbound[1:0] debug: refuse[42:0] D22B010000010000000000000767617465776179026665096170706C652D646E73036E657400001C0001 [1646963201] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 57806 (len 16) [1646963201] unbound[1:0] debug: refuse[42:0] 63A7010000010000000000000767617465776179026665096170706C652D646E73036E65740000010001 [1646963202] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 63744 (len 16) [1646963202] unbound[1:0] debug: refuse[42:0] 384E010000010000000000000767617465776179026665096170706C652D646E73036E65740000410001 [1646963202] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 63616 (len 16) [1646963202] unbound[1:0] debug: refuse[42:0] D22B010000010000000000000767617465776179026665096170706C652D646E73036E657400001C0001 [1646963202] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 57806 (len 16) [1646963202] unbound[1:0] debug: refuse[42:0] 63A7010000010000000000000767617465776179026665096170706C652D646E73036E65740000010001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54349 (len 16) [1646963486] unbound[1:0] debug: refuse[53:0] ECD40100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E65740000410001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 55781 (len 16) [1646963486] unbound[1:0] debug: refuse[53:0] C68C0100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E657400001C0001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 49825 (len 16) [1646963486] unbound[1:0] debug: refuse[53:0] DAC10100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E65740000010001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 52442 (len 16) [1646963486] unbound[1:0] debug: refuse[42:0] 170B010000010000000000000767617465776179026665096170706C652D646E73036E65740000410001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 51816 (len 16) [1646963486] unbound[1:0] debug: refuse[42:0] 1F4D010000010000000000000767617465776179026665096170706C652D646E73036E657400001C0001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56095 (len 16) [1646963486] unbound[1:0] debug: refuse[42:0] 9022010000010000000000000767617465776179026665096170706C652D646E73036E65740000010001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56025 (len 16) [1646963486] unbound[1:0] debug: refuse[30:0] 316901000001000000000000046D61696C046574687A0263680000410001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54050 (len 16) [1646963486] unbound[1:0] debug: refuse[30:0] 929501000001000000000000046D61696C046574687A02636800001C0001 [1646963486] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 60671 (len 16) [1646963486] unbound[1:0] debug: refuse[30:0] 1A5301000001000000000000046D61696C046574687A0263680000010001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54349 (len 16) [1646963487] unbound[1:0] debug: refuse[53:0] ECD40100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E65740000410001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 55781 (len 16) [1646963487] unbound[1:0] debug: refuse[53:0] C68C0100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E657400001C0001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 49825 (len 16) [1646963487] unbound[1:0] debug: refuse[53:0] DAC10100000100000000000007636C352D63646E0C6F726967696E2D6170706C6503636F6D06616B61646E73036E65740000010001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 52442 (len 16) [1646963487] unbound[1:0] debug: refuse[42:0] 170B010000010000000000000767617465776179026665096170706C652D646E73036E65740000410001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 51816 (len 16) [1646963487] unbound[1:0] debug: refuse[42:0] 1F4D010000010000000000000767617465776179026665096170706C652D646E73036E657400001C0001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56095 (len 16) [1646963487] unbound[1:0] debug: refuse[42:0] 9022010000010000000000000767617465776179026665096170706C652D646E73036E65740000010001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 56025 (len 16) [1646963487] unbound[1:0] debug: refuse[30:0] 316901000001000000000000046D61696C046574687A0263680000410001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 54050 (len 16) [1646963487] unbound[1:0] debug: refuse[30:0] 929501000001000000000000046D61696C046574687A02636800001C0001 [1646963487] unbound[1:0] debug: refused query from ip4 192.168.1.101 port 60671 (len 16) [1646963487] unbound[1:0] debug: refuse[30:0] 1A5301000001000000000000046D61696C046574687A0263680000010001
The logs in docker container logs unbound look like this (same procedure):
[1646962928] libunbound[18:0] error: udp connect failed: Cannot assign requested address for 2001:500:1::53 port 53 [1646962928] libunbound[18:0] error: udp connect failed: Cannot assign requested address for 2001:500:a8::e port 53 [1646962928] unbound[1:0] debug: creating udp4 socket 192.168.1.43 53 [1646962928] unbound[1: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. [1646962928] unbound[1:0] debug: creating tcp4 socket 192.168.1.43 53 [1646962928] unbound[1:0] debug: chdir to /opt/unbound/etc/unbound [1646962928] unbound[1:0] debug: chroot to /opt/unbound/etc/unbound [1646962928] unbound[1:0] debug: drop user privileges, run as _unbound [1646962928] unbound[1:0] debug: switching log to /opt/unbound/etc/unbound/unbound.log And if this helps, the docker network inspect looks like this:
[ { "Name": "dockernet", "Id": "da4d92648a57542f2aae1199246f421fe7aaae553e51235474ca2ae2569e81ab", "Created": "2022-01-19T23:26:58.966774026Z", "Scope": "local", "Driver": "ipvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.1.0/24", "Gateway": "192.168.1.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "616cb867dc8984af506ea696faceac262c367b5e199347a5aa68009041e08f09": { "Name": "unbound", "EndpointID": "192de7fd985bf5938c84ba77b201cd661227e4abc721b8d9d0d2636d615f8989", "MacAddress": "", "IPv4Address": "192.168.1.43/24", "IPv6Address": "" }, "b842c3afc82116f692ff9aa78161999cace950b4b2a53c5727be02a66abf34e9": { "Name": "nextcloud", "EndpointID": "e6856e1489cd18c7c69952aacbb971f216ae322ffbdf3bb08b99e35b965106a3", "MacAddress": "", "IPv4Address": "192.168.1.41/24", "IPv6Address": "" }, "ef04e7edec8bf14b23d8e6b4240372588c4ef677d4eed02cc26f1313f8434ef0": { "Name": "pihole", "EndpointID": "1c5e49e7102d63ea3ae47f04698fec76815a72c7f69ad6223fbaeb655143c765", "MacAddress": "", "IPv4Address": "192.168.1.42/24", "IPv6Address": "" } }, "Options": { "ipvlan_mode": "l2", "parent": "eth0" }, "Labels": {} } ]
I'm really not sure if this is a problem with docker or a problem with the image or with the config / unbound.
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.
AliSot2000
Hi I'm sorry to bother you but this seems to be the most suitable place to ask this question.
I have a Raspberry Pi with ubuntu-server 20.04.04 LTS. I'd like to have an unbound image running in on my pi. As I would like to be able to access the server from within the network and not only a pi-hole, which is also running on said rpi, I'm using it in a little bit different way.
I have created a IPv4 docker network to which both the pi-hole as well as the unbound server are connected (a Nextcloud is also using the same network if this is of concern)
I modified the config which is provided by the pi-hole install guide slightly to make it "suitable" for my needs. (I suspect an issue might lay here).
Anyway. I tried to start the container (just to be sure) with your recommended command on in the ReadMe.
However I got the following response:
It might have something to do with:
I would like to use this modified unbound.conf:
Which is as I mentioned a modified version from this: Pi-Hole-Docs
While starting, the container is healthy but as soon as it is running, it becomes unhealthy. I tried several times with different configs and debug levels but it always stays the same; the server refuses the queries.
Here are the logs on verbosity 4: (I created the container with the following start command and this is everything after it has been running)
docker run -d --network=dockernet --ip=192.168.1.43 --name=unbound -v=/mnt/SSD/docker_external_volumes/unbound/:/opt/unbound/etc/unbound --restart=unless-stopped mvance/unbound-rpi:latestThe logs in
docker container logs unboundlook like this (same procedure):And if this helps, the
docker network inspectlooks like this:I'm really not sure if this is a problem with docker or a problem with the image or with the config / unbound.