Re: Large Zone Transfers Failing in Latest Buster Update
On Fri, Aug 02, 2024 at 10:45:21AM -0400, Jeffrey Walton wrote:
> On Fri, Aug 2, 2024 at 10:37 AM Roberto C. Sánchez <roberto@debian.org> wrote:
> >
> > On Fri, Aug 02, 2024 at 10:16:51AM -0400, Jeffrey Walton wrote:
> > > On Fri, Aug 2, 2024 at 9:13 AM Brian <kimhick@yahoo.com> wrote:
> > > >
> > > > We just ran the latest updates for Debian Buster on one of our DNS servers running bind9 and one of the slave domains is failing with this message:
> > > >
> > > > Aug 2 07:05:20 <hostname> named[76759]: transfer of '<domain name>/IN' from <ip address>#53: Transfer status: too many records
> > > >
> > > > There are about 1,400 records in that domain which has never posed a problem in the past.
> > > >
> > > > We have tried force transfers, purging journal files and nothing seems to work.
> > > >
> > > > We rolled back the update to one performed earlier in the month and now everything is working.
> > > >
> > > > Anybody have any idea what is going on with this latest update?
> > >
> > > I think this might be "bind9 update 9.16.50 -- too many record" from
> > > the debian-security mailing list at
> > > <https://lists.debian.org/debian-security/2024/07/msg00003.html>.
> > >
> > Which seems unlikely on a system running buster.
>
> Maybe I am mis-parsing things, but the backporting to older Debian
> versions is discussed, starting with the question, "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?" The first answer appears at
> <https://lists.debian.org/debian-security/2024/07/msg00004.html>.
>
I agree that it is discussed as you say. However, that discussion is
about backporting the 9.20 configuration changes to bind9 in *bullseye*,
while the OP in this thread indicated that the problem was is in bind9
on a system running *buster*. The last bind9 update on buster [0] was
uploaded on 2024-05-17, and did not involve the 9.20 configuration
changes. So, the OP should be considering what else has changed that may
have caused the observed failure.
Regards,
-Roberto
[0] https://tracker.debian.org/news/1530724/accepted-bind9-19115p4dfsg-51deb10u11-source-into-oldoldstable/
--
Roberto C. Sánchez
Reply to: