Re: bind9 update 9.16.50 -- too many record
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)
ondrej@sury.org
> On 28. 7. 2024, at 10:10, Ondřej Surý <ondrej@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)
> ondrej@sury.org
>
>> On 28. 7. 2024, at 7:33, Salvatore Bonaccorso <carnil@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
>
Reply to: