| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 101:22:14 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,534 |
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?
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
The source package can be built from `debian/bullseye` branch of thehttps://salsa.debian.org/dns-team/bind9.git repository using
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 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
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.
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