Your message dated Wed, 26 Nov 2025 23:54:27 +0300
with message-id <[email protected]>
and subject line Re: Bug#1100870: unbound-anchor is unable to recover from full
disk
has caused the Debian Bug report #1100870,
regarding unbound-anchor is unable to recover from full disk
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1100870: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100870
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: unbound-anchor
Version: 1.17.1-2+deb12u2
Severity: important
Dear Maintainer,
We've been using unbound-anchor on our servers for a good while now and
we've been struggling with an issue that has an impact on the
reliability of the local DNS resolver.
When machines end up having their disk completely filled up,
unbound-anchor ends up squashing all of the files used as
auto-trust-anchor-file with just an empty file and can't add in the
expected contents. When this happens, the contents of the anchor files
are lost so unbound is 1. unable to start back up and 2. unable to
recover from the situation unless a human intervenes.
2 means that when this happens, dns can be broken for a while before we
realise that this situation is happening.
Luckily, upstream has already fixed this:
https://github.com/NLnetLabs/unbound/issues/595
The fix has been released with version 1.20, so we'll have it in trixie!
However, I was wondering if it could be possible to backport the patch
to bookworm so that users can have a more stable dns resolver until they
can upgrade to trixie.
The patch mentioned in the issue is relatively simple, so it shouldn't
bee too much of a hassle to backport, I think:
https://github.com/NLnetLabs/unbound/commit/8575d5b35ce3b91b41962fbba69030cc8789c3bf
Cheers!
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.12.17-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages unbound-anchor depends on:
ii libc6 2.41-5
ii libexpat1 2.7.0-1
ii libssl3t64 3.4.1-1
ii libunbound8 1.22.0-1+b1
unbound-anchor recommends no packages.
unbound-anchor suggests no packages.
--- End Message ---
--- Begin Message ---
Version: 1.20.0-1
Version: 1.20.0-1
On Wed, 19 Mar 2025 15:42:59 -0400 Gabriel Filion
<[email protected]> wrote:
Package: unbound-anchor
Version: 1.17.1-2+deb12u2
Severity: important
Dear Maintainer,
We've been using unbound-anchor on our servers for a good while now and
we've been struggling with an issue that has an impact on the
reliability of the local DNS resolver.
When machines end up having their disk completely filled up,
unbound-anchor ends up squashing all of the files used as
auto-trust-anchor-file with just an empty file and can't add in the
expected contents. When this happens, the contents of the anchor files
are lost so unbound is 1. unable to start back up and 2. unable to
recover from the situation unless a human intervenes.
2 means that when this happens, dns can be broken for a while before we
realise that this situation is happening.
Luckily, upstream has already fixed this:
https://github.com/NLnetLabs/unbound/issues/595
The fix has been released with version 1.20, so we'll have it in trixie!
However, I was wondering if it could be possible to backport the patch
to bookworm so that users can have a more stable dns resolver until they
can upgrade to trixie.
So, let's close it with version 1.20. And fix this for bookworm
in a separate upload.
Thanks,
/mjt
--- End Message ---
