Missed the Cc: to BTS first time. -- Ondřej Surý (He/Him) ond...@sury.org
> Begin forwarded message: > > From: Ondřej Surý <ond...@sury.org> > Subject: Re: Bug#987776: unblock: bind9/1:9.16.15-1 > Date: 17 May 2021 14:10:40 CEST > To: Salvatore Bonaccorso <car...@debian.org> > Cc: Paul Gevers <elb...@debian.org>, Debian Security Team > <t...@security.debian.org>, Debian Release Team Discussion > <t...@release.debian.org> > > Ok, here’s me adding little bit more of detail to the issue: > > 0. I am the Director of DNS Engineering at ISC - so I am as close to the > upstream as one can be. > 1. The most churn came from removing the upstream patches that fixed the XFR > timeouts. There was a bug when the TCP timeouts were not applied correctly > and `named` would drop the long transactions after the initial timeout. I > pulled the patches into the previous release directly from our git (after > they had been reviewed and merged) and dropped them in this release. > 2. The other churn came from the NSEC3-iteration patches that again have been > reviewed in the upstream and merged to the respective branches before I > pulled them into the Debian package. > 3. Since this BIND 9 release was a security release, the upstream (ISC) made > sure that only a minimal required set of changes would be included in this > current upstream stable release. The only non-security related stuff were > fixed in the DNSSEC KASP processing, a memory leak and fixes to the journal > upgrade processing[a]. > > a. As a matter of fact, we found just another edge condition here which might > cause IXFR to drop to AXFR when more than one journal transaction would be > used. But that will have to be fixed separately later, as we (upstream) seem > to struggle with fixing all the weird edge conditions, so I want to be 100% > sure we got everything. > > There’s another set of patches that I think we should pull into stable BIND 9 > when the dust settles. The BIND 9.16 recursive performance is really bad due > to the contention between new network threads and task threads. The code has > just landed in our upstream 9.16 branch, so I’ll give it some time before > requesting the SRU, but I think it would be for benefit of all the users that > use BIND 9 as recursors. > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@sury.org > >> On 14. 5. 2021, at 9:15, Salvatore Bonaccorso <car...@debian.org> wrote: >> >> Hi Ondrej, >> >> On Fri, May 07, 2021 at 07:40:31AM +0200, Paul Gevers wrote: >>> Hi Ondřej, >>> >>> On 06-05-2021 22:41, Ondřej Surý wrote: >>>> Hi Salvatore, >>>> >>>> thanks for following up. I will try to follow up tomorrow. Basically, >>>> the difference between the debian versions are because I pulled some >>>> extra upstream patches into the previous version and now I dropped them >>>> and pulled another set for the NSEC3 iterations issue. >>>> >>>> With my upstream hat, the 9.16 is stable release and we pull only >>>> important stuff into it. I am not asking for a long term exception as we >>>> have with PHP, but I am asking for an exception now. >>>> >>>> While I could pull all the important upstream changes to the “old” >>>> release, it would be a charade as most of the stuff needs to be picked >>>> up anyway. >>> >>> >>> These comments helped: >>> - Ondřej is upstream author too >>> - delta is partially in patches that are in the new version upstream >>> - 9.16 stable release with "only important stuff" >>> >>> For future reference, the release team also has a non-public list: >>> t...@release.debian.org. It better to not bet on one horse. >>> >>> I've unblocked bind9 and aged it. I'd still appreciate the follow-up in >>> the unblock request for the outside world (whatever you deem you can put >>> into it) such that I can close it. >> >> Thanks Paul for the unlbock. >> >> Friendly ping :). Sorry I d not want to be annoying, but guess Paul >> still would appreciate a followup to the public bug, OTOH I unerstand >> we do not wat to raise too much awareness on the issues you pointed >> out above. >> >> So be assured, this will the last ping from my side on this regard. >> >> Regards, >> Salvatore >
