Is anybody else seeing issues with the ports unbound locking up on 12.2-RELEASE-p2?

I've been running dns/unbound for quite a while (at least a couple of years) on multiple machines - for starters, both my mail server and my firewall box use it as caching dns server. Both use the same configuration, and have done so for months without any issues, if not longer.

Over the last couple of days I've had the unbound process going into what I'd call an "actively not doing anything" state where the process consumes all the CPU on one core and does not respond to control commands. In fact the only way to stop it before restarting it is to kill -9 the unbound process. As far as I can tell, this started a couple of days ago, within probably a week of me applying the -p2 patch set. I haven't got a core dump (yet) as I needed the system up and running, but will try to get one next time this happens. Have to check that the binaries aren't stripped, though.

I've attached the unbound.conf below in case there is a subtle or not so subtle problem with it, although I've been using the same config file for months now. Both machines also have IPV6 connectivity and unbound is configured to use both.

Is anybody else seeing this issue?

YAML:
server:
   # Log information, basic setup
   verbosity: 1
   statistics-interval: 300
   num-threads: 1
  
   access-control: 127.0.0.0/8 allow
   access-control: ::1 allow
   #access-control: 192.168.0.0/16 allow
   aggressive-nsec: yes
   cache-max-ttl: 86400
   cache-min-ttl: 600
   do-ip4: yes
   do-ip6: yes
   do-tcp: yes
   do-udp: yes
   hide-identity: yes
   hide-version: yes
   interface: 127.0.0.1
   interface: ::1
   minimal-responses: yes
   prefetch: yes
   #qname-minimisation: yes
   rrset-roundrobin: yes
   tls-upstream: yes
   tls-port: 853
   #use-caps-for-id: yes
   tls-cert-bundle: "/usr/local/share/certs/ca-root-nss.crt"
   use-syslog: yes
   log-servfail: yes
   private-address: 10.0.0.0/8
   private-address: 172.16.0.0/12
   private-address: 192.168.0.0/16
   private-address: 169.254.0.0/16
   private-address: fd00::/8
   private-address: fe80::/10
   # Attempt to improve response times a bit
   fast-server-permil: 550

forward-zone:
   name: "."
   forward-tls-upstream: yes
   forward-addr: 2606:4700:4700::1111@853#one.one.one.one
   forward-addr: 2620:fe::fe@853#dns.quad9.net
   forward-addr: 2606:4700:4700::1001@853#one.one.one.one
   forward-addr: 2001:4860:4860::8888@853#dns.google
   forward-addr: 2620:fe::9@853#dns.quad9.net
   forward-addr: 2001:4860:4860::8844@853#dns.google
   forward-addr: 1.1.1.1@853#one.one.one.one
   forward-addr: 9.9.9.9@853#dns.quad9.net
   forward-addr: 1.0.0.1@853#one.one.one.one
   forward-addr: 149.112.112.112@853#dns.quad9.net
   forward-addr: 8.8.8.8@853#dns.google
   forward-addr: 8.8.4.4@853#dns.google
   forward-addr: 84.200.69.80@53#resolver1.dns.watch
   forward-addr: 84.200.70.40@53#resolver.2dns.watch
   forward-addr: 2001:1608:10:25::1c04:b12f@53#resolver1.dns.watch
   forward-addr: 2001:1608:10:25::9249:d69b@53#resolver2.dns.watch
 
Unbound 1.13.0 locked up again on the mail server while I was typing this post, so I (hopefully temporarily) downgraded the unbound port to 1.12.0 to see if that exhibits the same behaviour or not.
 
I'm not sure if unbound uses OpenSSL, that last patch was for OpenSSL. Have you tried simply rebuilding the port after you applied the p2 patch? That may help. It may have had problems with the patched OpenSSL of p2.
 
I’m pretty sure it does, especially as I’m using DNS over TLS.

When the problem first showed up on my mail server, I did a forced recursive rebuild via port upgrade, but that didn’t help. This was after the -p2 update, as I also suspected an issue with the updated OpenSSL.

Right now it looks like the downgraded 1.12.0 is stable on my mail server, whereas another freshly built 1.13.0 on my firewall decided to SEGV rather than lock up. Downgraded that one to 1.12.0 as well this morning. Let’s see how well that keeps working over the next few days.

It’s interesting given that is the first stability issue I’ve had with unbound after running it for multiple years on both FreeBSD and OpenBSD.
 
To update on this issue - it looks like it is/was an issue with unbound 1.13. After downgrading to 1.12, the issues went away and my various unbound instances are back to their normal behaviour.

Now if only I could reproduce it well enough to create a bug report, but that's a different issue.
 
Back
Top