Open zilexa opened 1 year ago
Hey @zilexa, could you run docker exec unbound unbound -V
so I can see the build information?
Also, does your test work if you remove the +dnssec
from your query?
I am not sure if OP is still having this issue, but I am. All my dig requests to unbound return either a SERVFAIL or NOERROR. I am using docker-compose and the section specific to unbound looks like this:
...
unbound:
image: "klutchell/unbound:latest"
container_name: unbound
volumes:
- './support/root.hints:/etc/unbound/root.hints'
- './support/unbound.conf:/etc/unbound/unbound.conf'
networks:
adguard:
ipv4_address: 172.18.0.3
# ipv6_address: 2002:db8:abc1::3
restart: always
...
My unbound.conf looks like this (essentially the template provided except with changes to include logging and ipv6):
# https://linux.die.net/man/5/unbound.conf
# https://docs.pi-hole.net/guides/unbound/
server:
# Enable or disable whether the unbound server forks into the background
# as a daemon. Default is yes.
do-daemonize: no
# # If given, after binding the port the user privileges are dropped.
# # Default is "unbound". If you give username: "" no user change is performed.
username: "unbound"
# # No need to chroot as this container has been stripped of all other binaries.
chroot: ""
# # If "" is given, logging goes to stderr, or nowhere once daemonized.
logfile: ""
# # The process id is written to the file. Not required since we are running
# # in a container with one process.
pidfile: ""
# # The verbosity number, level 0 means no verbosity, only errors.
# # Level 1 gives operational information.
# # Level 2 gives detailed operational information.
# # Level 3 gives query level information, output per query.
# # Level 4 gives algorithm level information.
# # Level 5 logs client identification for cache misses.
# # Default is level 1. The verbosity can also be increased from the commandline.
verbosity: 1
log-queries: yes
# Listen on all ipv4 interfaces, answer queries from the local subnet.
interface: 0.0.0.0@53
## The port number, default 53, on which the server responds to queries.
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
# 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
# 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: yes
# Reduce EDNS reassembly buffer size (see also https://docs.pi-hole.net/guides/dns/unbound/ )
# 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
# Fetch DS records earlier (DNSSEC): more cpu usage, less latency
prefetch-key: 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: 2
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
# (requires CAP_NET_ADMIN or privileged)
# so-rcvbuf: 1m
# Increase cache size to utilize more RAM
msg-cache-size: 64m
rrset-cache-size: 128m
# This attempts to reduce latency by serving the outdated record before
# updating it instead of the other way around
# Default: cache-min-ttl: 0
serve-expired: yes
# The netblock is given as an IP4 or IP6 address with /size appended for a
# classless network block. The action can be deny, refuse, allow or allow_snoop.
access-control: 127.0.0.1/32 allow
access-control: 172.18.0.2/32 allow
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
# Read the root hints from this file. Default is nothing, using built in
# hints for the IN class. The file has the format of zone files, with root
# nameserver names and addresses only. The default may become outdated,
# when servers change, therefore it is good practice to use a root-hints
# file. get one from https://www.internic.net/domain/named.root
root-hints: /etc/unbound/root.hints
# File with trust anchor for one zone, which is tracked with RFC5011 probes.
# The probes are several times per month, thus the machine must be online frequently.
# The initial file can be one with contents as described in trust-anchor-file.
# The file is written to when the anchor is updated, so the unbound user must
# have write permission.
auto-trust-anchor-file: /etc/unbound/root.key
# Number of ports to open. This number of file descriptors can be opened per thread.
# Must be at least 1. Default depends on compile options. Larger numbers need extra
# resources from the operating system. For performance a very large value is best,
# use libevent to make this possible.
outgoing-range: 8192
# The number of queries that every thread will service simultaneously. If more queries
# arrive that need servicing, and no queries can be jostled out (see jostle-timeout),
# then the queries are dropped. This forces the client to resend after a timeout;
# allowing the server time to work on the existing queries. Default depends on
# compile options, 512 or 1024.
num-queries-per-thread: 4096
# If null or "", no file is used. Set it to the certificate bun-
# dle file, for example "/etc/pki/tls/certs/ca-bundle.crt". These
# certificates are used for authenticating connections made to
# outside peers. For example auth-zone urls, and also DNS over
# TLS connections. It is read at start up before permission drop
# and chroot.
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
# Allow custom configuration to override the settings above
include-toplevel: /etc/unbound/custom.conf.d/*.conf
The output of running docker exec unbound dig sigok.verteiltesysteme.net @127.0.0.1 +dnssec
(same result without the +dnssec):
; <<>> DiG 9.16.27 <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 53 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14744
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;sigok.verteiltesysteme.net. IN A
;; Query time: 140 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 28 00:45:08 UTC 2022
;; MSG SIZE rcvd: 55
And finally, the output of running docker exec unbound unbound -V
:
Version 1.17.0
Configure line: --target=aarch64-buildroot-linux-musl --host=aarch64-buildroot-linux-musl --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix= --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --disable-dependency-tracking --enable-ipv6 --disable-nls --disable-static --enable-shared --disable-rpath --disable-debug --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/var/run/unbound.pid --with-rootkey-file=/etc/unbound/root.key --enable-tfo-server --with-libevent=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --with-libexpat=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --with-ssl=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --enable-tfo-client --with-pthreads --enable-flto --enable-dnscrypt
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 1.1.1q 5 Jul 2022
Linked modules: dns64 respip validator iterator
DNSCrypt feature available
TCP Fastopen feature available
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
I am not sure if OP is still having this issue, but I am. All my dig requests to unbound return either a SERVFAIL or NOERROR. I am using docker-compose and the section specific to unbound looks like this:
... unbound: image: "klutchell/unbound:latest" container_name: unbound volumes: - './support/root.hints:/etc/unbound/root.hints' - './support/unbound.conf:/etc/unbound/unbound.conf' networks: adguard: ipv4_address: 172.18.0.3 # ipv6_address: 2002:db8:abc1::3 restart: always ...
My unbound.conf looks like this (essentially the template provided except with changes to include logging and ipv6):
# https://linux.die.net/man/5/unbound.conf # https://docs.pi-hole.net/guides/unbound/ server: # Enable or disable whether the unbound server forks into the background # as a daemon. Default is yes. do-daemonize: no # # If given, after binding the port the user privileges are dropped. # # Default is "unbound". If you give username: "" no user change is performed. username: "unbound" # # No need to chroot as this container has been stripped of all other binaries. chroot: "" # # If "" is given, logging goes to stderr, or nowhere once daemonized. logfile: "" # # The process id is written to the file. Not required since we are running # # in a container with one process. pidfile: "" # # The verbosity number, level 0 means no verbosity, only errors. # # Level 1 gives operational information. # # Level 2 gives detailed operational information. # # Level 3 gives query level information, output per query. # # Level 4 gives algorithm level information. # # Level 5 logs client identification for cache misses. # # Default is level 1. The verbosity can also be increased from the commandline. verbosity: 1 log-queries: yes # Listen on all ipv4 interfaces, answer queries from the local subnet. interface: 0.0.0.0@53 ## The port number, default 53, on which the server responds to queries. port: 53 do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes # 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 # 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: yes # Reduce EDNS reassembly buffer size (see also https://docs.pi-hole.net/guides/dns/unbound/ ) # 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 # Fetch DS records earlier (DNSSEC): more cpu usage, less latency prefetch-key: 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: 2 # Ensure kernel buffer is large enough to not lose messages in traffic spikes # (requires CAP_NET_ADMIN or privileged) # so-rcvbuf: 1m # Increase cache size to utilize more RAM msg-cache-size: 64m rrset-cache-size: 128m # This attempts to reduce latency by serving the outdated record before # updating it instead of the other way around # Default: cache-min-ttl: 0 serve-expired: yes # The netblock is given as an IP4 or IP6 address with /size appended for a # classless network block. The action can be deny, refuse, allow or allow_snoop. access-control: 127.0.0.1/32 allow access-control: 172.18.0.2/32 allow # Ensure privacy of local IP ranges private-address: 192.168.0.0/16 private-address: 169.254.0.0/16 private-address: 172.16.0.0/12 private-address: 10.0.0.0/8 private-address: fd00::/8 private-address: fe80::/10 # Read the root hints from this file. Default is nothing, using built in # hints for the IN class. The file has the format of zone files, with root # nameserver names and addresses only. The default may become outdated, # when servers change, therefore it is good practice to use a root-hints # file. get one from https://www.internic.net/domain/named.root root-hints: /etc/unbound/root.hints # File with trust anchor for one zone, which is tracked with RFC5011 probes. # The probes are several times per month, thus the machine must be online frequently. # The initial file can be one with contents as described in trust-anchor-file. # The file is written to when the anchor is updated, so the unbound user must # have write permission. auto-trust-anchor-file: /etc/unbound/root.key # Number of ports to open. This number of file descriptors can be opened per thread. # Must be at least 1. Default depends on compile options. Larger numbers need extra # resources from the operating system. For performance a very large value is best, # use libevent to make this possible. outgoing-range: 8192 # The number of queries that every thread will service simultaneously. If more queries # arrive that need servicing, and no queries can be jostled out (see jostle-timeout), # then the queries are dropped. This forces the client to resend after a timeout; # allowing the server time to work on the existing queries. Default depends on # compile options, 512 or 1024. num-queries-per-thread: 4096 # If null or "", no file is used. Set it to the certificate bun- # dle file, for example "/etc/pki/tls/certs/ca-bundle.crt". These # certificates are used for authenticating connections made to # outside peers. For example auth-zone urls, and also DNS over # TLS connections. It is read at start up before permission drop # and chroot. tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt # Allow custom configuration to override the settings above include-toplevel: /etc/unbound/custom.conf.d/*.conf
The output of running
docker exec unbound dig sigok.verteiltesysteme.net @127.0.0.1 +dnssec
(same result without the +dnssec):; <<>> DiG 9.16.27 <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 53 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14744 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;sigok.verteiltesysteme.net. IN A ;; Query time: 140 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Dec 28 00:45:08 UTC 2022 ;; MSG SIZE rcvd: 55
And finally, the output of running
docker exec unbound unbound -V
:Version 1.17.0 Configure line: --target=aarch64-buildroot-linux-musl --host=aarch64-buildroot-linux-musl --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix= --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --disable-dependency-tracking --enable-ipv6 --disable-nls --disable-static --enable-shared --disable-rpath --disable-debug --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/var/run/unbound.pid --with-rootkey-file=/etc/unbound/root.key --enable-tfo-server --with-libevent=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --with-libexpat=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --with-ssl=/home/br-user/buildroot/output/host/aarch64-buildroot-linux-musl/sysroot/usr --enable-tfo-client --with-pthreads --enable-flto --enable-dnscrypt Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 1.1.1q 5 Jul 2022 Linked modules: dns64 respip validator iterator DNSCrypt feature available TCP Fastopen feature available BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
Update: I've manually created ubuntu docker container and installed unbound and its required dependency and DNSSEC validation seems to work fine. I'm thinking this is image related but I could be wrong.
I've been using this docker container for quite a while without problems, so your assumption it must be this container seems off.
Have you tried commenting out the line that refers to root.hints in your conf file? Seems the first potential culprit as this container comes with one and I've seen another case where a user defined filed caused issues. In any case, the root.hints file included here should be sufficient.
Furthermore, to make life easier (and this is not necessarily related to the issue at hand), I would suggest to review your conf file and minimize the specific items to those you know are useful and impact full for your specific situation. Makes debugging easier as well 😊 (just sharing something I've learned along the way)
I've been using this docker container for quite a while without problems, so your assumption it must be this container seems off.
Have you tried commenting out the line that refers to root.hints in your conf file? Seems the first potential culprit as this container comes with one and I've seen another case where a user defined filed caused issues. In any case, the root.hints file included here should be sufficient.
Furthermore, to make life easier (and this is not necessarily related to the issue at hand), I would suggest to review your conf file and minimize the specific items to those you know are useful and impact full for your specific situation. Makes debugging easier as well 😊 (just sharing something I've learned along the way)
I just checked again, and you are right! I think my issue was related to DNS Cache and my router forwarding DNS requests to its own servers if a DNS server doesn't exist.
Side Note: I also discovered that Lima isn't able to port forward UDP ports and that was the reason for why my dig commands would fail when trying to query unbound. Adding +tcp
would let them succeed.
Hi I'm the OP. Strangely, it only seems to be an issue the first 24hrs after recreating the container. The test works afterwards. So perhaps some kind of caching issue.
I still have this issue. I use Adguard Home (network_mode: host) and Unbound (using docker bridge network). When the Unbound container is recreated or removed/newly created, I cannot resolve DNS for at least 24 hours.
When i simply change the DNS server from my Unbound container (127.0.0.1:5335) to for example 1.1.1.1, all works fine immediately.
Quite annoying when you reboot your server.
That is odd, and it could be linked to a number of things it seems.
Did you try a simple dig command in the CLI to test Unbound individually? (just to check if the Unbound container works in an isolated way)
FYI, I run Pi-Hole and Unbound in Docker, using Docker Compose and have never faced something along the lines of what you describe. How do you create the containers? (besides that, as mentioned, there could be multiple things at play here such as DNSSEC issues linked to bad time setting etc)
I still have this issue. I changed the temp solution 1.1.1.1 back to 192.168.88.2:5335 and it worked. Then this morning I rebooted my server and as expected, Unbound stopped working (no config changed whatsoever).
So I thought I start fresh:
dns-unbound:
container_name: net-dns-unbound
image: klutchell/unbound:latest
hostname: unbound
restart: always
environment:
TZ: $TZ
ports:
- 5354:53/tcp
- 5354:53/udp
When testing on the host:
docker exec net-dns-unbound dig google.com @127.0.0.1
; <<>> DiG 9.16.33 <<>> google.com @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44112 ;; 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: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Sep 03 09:14:28 UTC 2023 ;; MSG SIZE rcvd: 39
docker exec net-dns-unbound dig google.com @127.0.0.1 +tcp
; <<>> DiG 9.16.33 <<>> google.com @127.0.0.1 +tcp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5501 ;; 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: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Sep 03 09:15:15 UTC 2023 ;; MSG SIZE rcvd: 39
More info:
docker exec net-dns-unbound unbound -V Version 1.17.1
Configure line: --target=x86_64-buildroot-linux-musl --host=x86_64-buildroot-linux-musl --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix= --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --disable-dependency-tracking --enable-ipv6 --disable-nls --disable-static --enable-shared --disable-rpath --disable-debug --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/var/run/unbound.pid --with-rootkey-file=/etc/unbound/root.key --enable-tfo-server --with-libevent=/home/br-user/buildroot/output/host/x86_64-buildroot-linux-musl/sysroot/usr --with-libexpat=/home/br-user/buildroot/output/host/x86_64-buildroot-linux-musl/sysroot/usr --with-ssl=/home/br-user/buildroot/output/host/x86_64-buildroot-linux-musl/sysroot/usr --enable-tfo-client --with-pthreads --enable-flto --enable-dnscrypt Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 1.1.1q 5 Jul 2022 Linked modules: dns64 respip validator iterator DNSCrypt feature available TCP Fastopen feature available
BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
Running Manjaro Gnome on an Intel based system, wired connected to my Mikrotik RouterOS router (with a Netgear switch in between).
I'm pretty sure if I test tomorrow, all is fine again..
I did not even have to wait that long. It already works now, couple hours later, without changing anything.
I even switched back to my "own" config, in which I set the port to 5335 and loglevel "2". This way, I can run Unbound in "network_mode: host". This way I can simply use 192.168.88.2:5335 in AdGuard Home (my server IP address).
If I do not run Unbound in host network mode, I am forced to use the IP address of the docker container in AdGuard Home (172.19.0.2:53, because 192.168.88.2:5335 doesn't work, it makes no sense, but it doesn't work). Something I do not want, because theoretically a different IP could get assigned when I stop the container or recreate the container.
I still do not understand why I have to wait several hours before Unbound works again.
I've struggled with docker for a while when trying to combine pi-hole and unbound as well (pi-hole and adguard home serve the same purpose). For me, things also only seem to work using the host network driver. And even stranger, despite setting the 5335 port as you do, it uses 53... I out it down to (a) my lack of knowledge of Docker and networking and/or (b) a quirk in Docker... (option a seems more likely in my case)
@churchofnoise I think you are confusing things? When you use hostmode, you cannot set ports in docker. The port in unbound.conf will be listened to, in my case that is definitely 5335 (see my config in the prev post). I also confirmed the default Unbound (without any volume mapped, so no custom config) image and its config work just fine in non-host mode.
So for me the issue is not that this image doesn't work, or only works in host mode. It works in both modes and listens to the expected port...
It just does not work after a reboot, for a couple of hours... which makes absolutely no sense to me.
Apologies, you are right... I have it in bridge mode BTW...
I still do not understand why I have to wait several hours before Unbound works again.
Maybe it has something to do with timestamps? Try mounting /etc/localtime:/etc/localtime:ro
in the unbound container? I ask because it looks like unbound is replying, but treating the response as insecure. If logging is increased does unbound show the reason for the SERVFAIL?
Also I should note the latest releases of klutchell/unbound:latest
do not use buildroot, and replaced dig
with drill
, so if you re-pull the image some things will behave differently. Maybe better?
I believe this is the test to confirm it isn't working:
I never configure anything for unbound, I just dump 127.0.0.1:5335 in Adguard Home as my only DNS server.
I did not modify my Docker Compose.
Log, obtained through Portainer:
Why did it stop working?