I've now also ported all the changes to the system tests, so I can confirm the changes are correct and I've now uploaded the version with configuration options to security-master.
This means that information in: https://kb.isc.org/docs/rrset-limits-in-zones also applies to bind9_9.16.50-1~deb11u2. Salvatore, when you are communicating this, I would frame this as an improvement to the original patches. It is still recommended to upgrade to bookworm though. Ondrej -- Ondřej Surý (He/Him) ond...@sury.org > On 28. 7. 2024, at 10:10, Ondřej Surý <ond...@sury.org> wrote: > > Hey, > > I've successfully backported the configuration options from 9.18 to 9.16, > so if you need to bump the limits, it will be possible in the next upload. > > That said, I don't currently have a repository where I can upload the > updated packages, so I'll do the upload to security master, but before > Salvatore pushes this to everybody, I think this deserves some testing > from people that will use the options. > > The source package can be built from `debian/bullseye` branch of the > https://salsa.debian.org/dns-team/bind9.git repository using git-buildpackage. > Please report back. > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@sury.org > >> On 28. 7. 2024, at 7:33, Salvatore Bonaccorso <car...@debian.org> wrote: >> >> Hi, >> >> [looping in explicitly Ondrej, maintainer of bind9] >> >> On Fri, Jul 26, 2024 at 03:40:30PM -0400, Lee wrote: >>> On Fri, Jul 26, 2024 at 11:24 AM Guillaume Bienkowski wrote: >>>> >>>> Hello, >>> >>> Hi >>> >>>> We are using bind9 with many SRV entries to allow for dynamic discovery of >>>> hosts to monitor in our infrastructure. We have 300+ SRV records for the >>>> same domain name. >>>> >>>> After the security update of tonight (9.16.48 -> 9.16.50), our DNS server >>>> never rebooted. A named-zonecheck would issue error messages about "too >>>> many records". >>> >>> <.. snip before/after example ..> >>>> From my understanding, it seems that the number of unique records for the >>>> same domain name is now limited to 100, without any way to change it in >>>> named.conf. >>>> >>>> In the 9.20 version of bind9, it looks like they introduced a >>>> configuration value to set this limit (probably because the 100 limit is a >>>> bit restrictive), but this doesn't exist in the security backport. >>>> >>>> Here is their documentation on the subject: >>>> https://kb.isc.org/docs/rrset-limits-in-zones >>> >>> <.. snip ..> >>> >>>> In the meantime we had to pin the version to 9.16.48. >>> >>> which is from Debian 11 >>> >>>> Is this a conscious choice to solve the CVE? >>> >>> Yes. From the bind9 security update email of July 25 >>> >>> - For the oldstable distribution (bullseye), these problems have been >>> - fixed in version 1:9.16.50-1~deb11u1. For the oldstable distribution >>> - (bullseye) the limits to mitigate CVE-2024-1737 are hardcoded and not >>> - configurable. >>> >>> It also has >>> >>> - For the stable distribution (bookworm), these problems have been fixed in >>> - version 1:9.18.28-1~deb12u1. >>> >>>> Would you be willing to backport the configuration of 9.20 so that >>>> companies using larger record number per name can still use bind9 with >>>> security update? >>> >>> I don't know how accurate the wiki is, but >>> https://wiki.debian.org/DebianReleases#Production_Releases >>> has Bullseye / Debian 11 going end of life this month. >>> >>> I also don't know how much the Debian security team relies on upstream >>> for patches, but the ISC notice for security fixes doesn't even >>> mention 9.16: >>> https://lists.isc.org/pipermail/bind-users/2024-July/108763.html >>> >>> Considering end-of-life for Debian 11 is rapidly approaching and what >>> you're asking for exists in the current stable release (Debian 12/ >>> bind 9.18), maybe you should be considering upgrading to the current >>> Debian stable release? >> >> That is correct, bind9 will move the the LTS mainteinance in august. >> Regular security support wil lend on 14th of august, after that a >> final point release will happen, and after that the Debian LTS project >> will take over the mainteinance of bullseye with a reduced >> architecture set: >> >> https://lists.debian.org/debian-announce/2024/msg00001.html >> >> The choice for the backporting of fixes to bullseye a choice in >> balancing the backports for a version not anymore supported upstream >> vs. getting the fix in bullseye. If you need more than 100 as in the >> hardcoded limit, moving to bookworm is your best option to get a >> ersion of bind9 which is supported as well upstream. >> >> I will let Ondrej comment further as it still would be an option to >> try to backport the changes such that a hardcoded limit is not needed. >> >> Ondrej, if think it is feasible, maybe we can have that change >> included in the upcoming last point release for bullseye? >> >> Regards, >> Salvatore >
