This bug was fixed in the package bind9 - 1:9.18.18-0ubuntu0.22.04.1
---------------
bind9 (1:9.18.18-0ubuntu0.22.04.1) jammy; urgency=medium
* New upstream release 9.18.18 (LP: #2028413)
- Updates:
+ Mark a primary server as temporarily unreachable when a TCP connection
response to an SOA query times out, matching behavior of a refused TCP
connection.
+ Mark dialup and heartbeat-interval options as deprecated.
+ Retry DNS queries without an EDNS COOKIE when the first response is
FORMERR with the EDNS COOKIE that was sent originally.
+ Use NS records for the relaxed QNAME minimization mode to reduce the
number of queries from named.
+ Mark TKEY mode 2 as deprecated.
+ Mark delegation-only and root-delegation-only as deprecated.
+ Run RPZ and catalog zone updates on specialized offload threads to
reduce blocked query processing time.
- Bug Fixes:
+ Fix assertion failure from processing already-queued queries while
server is being reconfigured or cache is being flushed.
+ Fix failure to load zones containing resource records with a TTL value
larger than 86400 seconds when dnssec-policy is set to insecure.
+ Fix the ability to read HMAC-MD5 key files (LP: #2015176).
+ Fix stability issues with the catalog zone implementation.
+ Fix bind9 getting stuck when listen-on statement for HTTP is removed
from configuration.
+ Do not return delegation from cache after stale-answer-client-timeout.
+ Fix failure to auto-tune clients-per-query limit in some situations.
+ Fix proper timeouts when using max-transfer-time-in and
max-transfer-idle-in statements.
+ Bring rndc read timeout back to 60 seconds from 30.
+ Treat libuv returning ISC_R_INVALIDPROTO as a network error.
+ Clean up empty-non-terminal NSEC3 records.
+ Fix log file rotation cleanup for absolute file path destinations.
+ Fix various catalog zone processing crashes.
+ Fix transfer hang when downloading large zones over TLS.
+ Fix named crash when adding a new zone into the configuration file for
a name which was already configured as member zone for a catalog zone.
+ Delay DNSSEC key queries until all zones have finished loading.
- See https://bind9.readthedocs.io/en/v9.18.18/notes.html for additional
information.
* d/p/CVE-2023-2828.patch, CVE-2023-2911.patch: Remove - fixed upstream in
9.18.16.
* d/p/CVE-2023-3341.patch: Refresh, matching upstream, to apply in 9.18.18.
* d/t/control, d/t/dyndb-ldap: add DEP8 test (LP: #2032650)
-- Lena Voytek <lena.voy...@canonical.com> Wed, 20 Sep 2023 15:15:41
-0700
** Changed in: bind9 (Ubuntu Jammy)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of FreeIPA,
which is subscribed to bind-dyndb-ldap in Ubuntu.
https://bugs.launchpad.net/bugs/2032650
Title:
Add DEP8 tests for bind-dyndb-ldap integration
Status in bind-dyndb-ldap package in Ubuntu:
Fix Released
Status in bind9 package in Ubuntu:
Fix Released
Status in bind-dyndb-ldap source package in Jammy:
Fix Released
Status in bind9 source package in Jammy:
Fix Released
Status in bind-dyndb-ldap source package in Lunar:
Fix Committed
Status in bind9 source package in Lunar:
Fix Released
Status in bind-dyndb-ldap source package in Mantic:
Fix Released
Status in bind9 source package in Mantic:
Fix Released
Bug description:
[ Impact ]
bind-dyndb-ldap breaks very frequently with bind9 updates. Both must
have DEP8 tests so these breakages can be caught before a release.
[ Test Plan ]
For both packages, the test plan consists in having the new dyndb-ldap
DEP8 test run and succeed.
[ Where problems could occur ]
With this new DEP8 change, a bind9 update can be blocked by a bind-dyndb-ldap
failure to build or run with it.
While this is exactly the intent (not leave a broken bind-dyndb-ldap
package in the release), there is a history indicating that bind-
dyndb-ldap can be late in catching up to bind9 changes. We may reach a
situation where an important bind9 security update, for example, will
be blocked by a failing dyndb-ldap test, and it may be difficult to
fix bind-dyndb-ldap in time, specially if the security update is under
embargo and the bind-dyndb-ldap developers do not yet have details of
the changes.
[ Other Info ]
The same test is to be applied to the bind9 package, and is already in
mantic. But SRUs for DEP8 changes only are frowned upon, so the plan is to
upload it to proposed and block it there, but AFTER bind-dyndb-ldap has been
released.
The tight coupling between bind9 and bind-dyndb-ldap is problematic
(see [1], [2] and [3]). The moment a new bind9 hits proposed with this
test, it fill fail until a new bind-dyndb-ldap is rebuilt with that
proposed version.
One option would perhaps to accept a one-time DEP8-only change for
bind9, so that we can upload both packages together, instead of
leaving this in proposed with a blocking tag, to be picked up by the
next bind9 "real" update?
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503
2. https://pagure.io/bind-dyndb-ldap/issue/225
3. https://salsa.debian.org/dns-team/bind9/-/merge_requests/21
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind-dyndb-ldap/+bug/2032650/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~freeipa
Post to : freeipa@lists.launchpad.net
Unsubscribe : https://launchpad.net/~freeipa
More help : https://help.launchpad.net/ListHelp
