Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #6337 > unrolled thread

bind9 update 9.16.50 -- too many record

Back to article view | Back to linux.debian.security

Contents

  bind9 update 9.16.50 -- too many record Guillaume Bienkowski <guillaume.bienkowski@braincube.com> - 2024-07-26 17:30 +0200
    Re: bind9 update 9.16.50 -- too many record Lee <ler762@gmail.com> - 2024-07-26 21:50 +0200
      Re: bind9 update 9.16.50 -- too many record Salvatore Bonaccorso <carnil@debian.org> - 2024-07-28 07:40 +0200
        Re: bind9 update 9.16.50 -- too many record Ondřej Surý <ondrej@sury.org> - 2024-07-28 10:30 +0200
          Re: bind9 update 9.16.50 -- too many record Guillaume Bienkowski <guillaume.bienkowski@braincube.com> - 2024-07-28 18:30 +0200
          Re: bind9 update 9.16.50 -- too many record Ondřej Surý <ondrej@sury.org> - 2024-07-29 12:20 +0200
            Re: bind9 update 9.16.50 -- too many record Salvatore Bonaccorso <carnil@debian.org> - 2024-07-29 15:30 +0200
              Re: bind9 update 9.16.50 -- too many record Guillaume Bienkowski <guillaume.bienkowski@braincube.com> - 2024-11-28 10:30 +0100

#6337 — bind9 update 9.16.50 -- too many record

[Multipart message — attachments visible in raw view] — view raw

Hello,

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".

Before:

    root@dns-ext:/var/lib/bind# named-checkzone xxx.com db.xxx.com
    zone xxx.com/IN: loaded serial 2407240122
    OK

After:

    root@dns-ext:/var/lib/bind# named-checkzone xxx.com db.xxx.com
    [...]
    dns_master_load: db.xxx.com:1892: _healthchecks._tcp.iot.xxx.com: too
many records
    dns_master_load: db.xxx.com:1893: _hosts._tcp.iot.xxx.com: too many
records
    dns_master_load: db.xxx.com:1894: _healthchecks._tcp.iot.xxx.com: too
many records
    zone xxx.com/IN: loading from master file db.xxx.com failed: too many
records
    zone xxx.com/IN: not loaded due to errors.

>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

Also, from what I gathered from the patches, you override the
"non-changeable" limit to 5000 in the build script, but only for developer
mode:

diff --git a/configure b/configure
index 30e65f1..835cd94 100755
--- a/configure
+++ b/configure
@@ -12341,7 +12341,7 @@ fi

 XTARGETS=
 if test "$enable_developer" = "yes"; then :
-  STD_CDEFINES="$STD_CDEFINES -DISC_MEM_DEFAULTFILL=1
-DISC_LIST_CHECKINIT=1 -DDNS_RDATASET_MAX_RECORDS=5000"
+  STD_CDEFINES="$STD_CDEFINES -DISC_MEM_DEFAULTFILL=1
-DISC_LIST_CHECKINIT=1 -DDNS_RDATASET_MAX_RECORDS=5000
-DDNS_RBTDB_MAX_RTYPES=5000"
        test "${enable_fixed_rrset+set}" = set || enable_fixed_rrset=yes
        test "${enable_querytrace+set}" = set || enable_querytrace=yes
        test "${with_cmocka+set}" = set || with_cmocka=yes
diff --git a/configure.ac b/configure.ac
index ffe087e..6db4250 100644
--- a/configure.ac
+++ b/configure.ac

In the meantime we had to pin the version to 9.16.48.

Is this a conscious choice to solve the CVE?
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?


Thanks for your work!
Guillaume

[toc] | [next] | [standalone]

#6338

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?

Regards,
Lee

[toc] | [prev] | [next] | [standalone]

#6339

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

[toc] | [prev] | [next] | [standalone]

#6340

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

[toc] | [prev] | [next] | [standalone]

#6341

[Multipart message — attachments visible in raw view] — view raw

Hello and thank you all for your answers.

Indeed we might push the update to Bookworm four our DNS servers, or wait
for the backports version to reach 9.18.28 (where the configuration option
exists, which is not yet the case for the 9.16.24 that's available right
now).

> 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

Ondřej, I'll try to check if our problematic zone works fine with the 9.16
patched with the option next week and get back to you through here, thank
you for looking into it.

Best regards to you all and have a good sunday.
Guillaume

On Sun, Jul 28, 2024 at 10:10 AM 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]
> >
>

[toc] | [prev] | [next] | [standalone]

#6342

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
> 

[toc] | [prev] | [next] | [standalone]

#6343

Hi Ondrej,

On Mon, Jul 29, 2024 at 12:14:01PM +0200, Ondřej Surý wrote:
> 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.

I was actually aiming to see this followup improvement via the last
point release, but I think now it's equally well to release a followup
DSA.

You have tested patches, but still would be good to have a
confirmation from Guillaume, before the followup goes out.

> It is still recommended to upgrade to bookworm though.

Ack!

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#6379

[Multipart message — attachments visible in raw view] — view raw

Hi Lee, Ondrej, Salvatore

I didn't follow up on this because your backport of the configuration
settings was done  after my original message in August: the
9.16.50-1~deb11u2 version, which landed during my holiday break.

Since then, we are able to set the appropriate configuration settings to
enable more than 100 SRV records and our Bind9 instance is running fine.

So on my side this is fixed, and I thank the maintainers for having
backported the config options.
My original complaint was that we had a functional regression in a security
update, and no way of recovering a working bind9 without these
configuration settings. We had to resort to pin an older version (the -48
version), and Ondrej what you did with deb11u2 fixed our issue.

Thank you for looking back at this thread anyway. Bookworm is in our sights
so we'll have a more recent version of the package.

Guillaume

On Wed, Nov 27, 2024 at 11:32 PM Salvatore Bonaccorso <carnil@debian.org>
wrote:

> Hi Ondrej,
>
> On Mon, Jul 29, 2024 at 12:14:01PM +0200, Ondřej Surý wrote:
> > 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.
>
> I was actually aiming to see this followup improvement via the last
> point release, but I think now it's equally well to release a followup
> DSA.
>
> You have tested patches, but still would be good to have a
> confirmation from Guillaume, before the followup goes out.
>
> > It is still recommended to upgrade to bookworm though.
>
> Ack!
>
> Regards,
> Salvatore
>
>

-- 



  Guillaume Bienkowski
  Infrastructure Manager
  +33 6 18 30 78 10
[image: Braincube LinkedIn]
<https://www.linkedin.com/company/braincubefr/> [image:
Braincube Facebook]
<https://www.facebook.com/braincube.manufacturing.intelligence/> [image:
Braincube Twitter] <https://twitter.com/braincubeen> braincube.com

[image: AI readiness assessment]
<https://info.braincube.com/l/801593/2024-08-05/5fhlmv>
*To learn more about the management of your personal data and your
rights, click here <https://braincube.com/privacy-policy/>.*

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web