Fully automated DNSSEC with BIND 9.16

Mon Apr 17 18:40:21 UTC 2023

Ondřej,

it would be awesome if we could choose a higher quality release instead 
to use for our longer support. But we lack any good metric to choose 
one. So we update from time to time unless there is something stopping us.

On 4/17/23 14:49, Ondřej Surý wrote:
> Petr,
>
> while I understand that you are trying to do a great job maintaining
> the BIND 9 packages for RHEL, it is what it is - a random snapshot
> defined not by the quality of the chosen version but by the time
> availability. This is made even more complicated by applying a set
> of patches where the set is defined by the downstream maintainer.
>
> The whole idea that something frozen in time with patches applied
> by distribution maintainer must be more stable than the software
> actively developed by upstream developers is wrong. This could
> perhaps work for slow-paced low complex software, but for anything
> that's reasonably complex (as various network servers and clients
> are) it's doomed to fail.
Well, depends on how you define "stable". The less changes made makes it 
more stable in my opinion. Of course that is not necessary better, but 
it suits some people. For people with special demands every release 
might bring something important. But most people needs just something 
that works and does not require attention often. I do not think our RHEL 
is low complex software.
>
> And what's even worse that people will come, use the distribution
> package of BIND 9 and think this is the "best" quality they can get.
Quality of the package is hard to measure. We spend more time with 
integrating bind into the whole system. I admit we lack people working 
on each DNS peculiarities, we spend more time dealing with strange 
interactions in some conditions. I think that has also its value. I 
think distributions provide good enough packages often. It may not suit 
everyone, but it did not seem to me this were that case.
>> If he wanted bleeding edge
> This narrative is wrong. I am not recommending people to
> run the latest development release - that would be "bleeding edge".

Okay, bleeding edge were wrong word. Anyway, original question were not 
about the latest feature added. Our version can provide automated dnssec 
service just fine.

By the way, we have packaged even development version on Fedora under 
package bind9-next. Because it conflicts with bind system package, it 
were not allowed into EPEL (yet). Until I prepare a package that does 
not conflict, my copr can be used for EPEL 8 or 9:

https://copr.fedorainfracloud.org/coprs/pemensik/bind9-next/

> The latest stable BIND 9 version is not bleeding edge. You are trying to
> frame it as it's something dangerous to use the latest version provided
> by the upstream developers who are in all due respect more
> knowledgeable about the upstream source code than any downstream
> package maintainer could be. Sure, that doesn't mean that mistakes
> doesn't happen, they do, but running latest upstream patch release
> (or latest stable release) is considerably more safe for BIND 9 than
> running BIND 9 release that's many version behind, often EOL and
> with considerable amount of patches[1] applied.

Sure, we have quite long list of patches on top of bind 9.11. We still 
support dhcp server and client in RHEL8. That depends on bind libraries 
functionality, which is not provided by bind 9.16 anymore. We have not 
stayed on old version because we are lazy, but because more recent 
version does not provide compatible interface anymore. You know that.

I admit knowledge of BIND9 internals is far more advanced at ISC than at 
Red Hat, it has to be. I do not ask you to support our old versions. But 
just don't tell people to avoid vendor version, just because they are 
not sure how to configure relative basic thing. If that does not work 
when it should, okay, blame us. We deserve it often. This is not the 
case IMHO.

>
> So, no, I am not going to stop telling people to stop using packages
> bundled with a distribution unless the distribution follows the latest
> patch release.
They do on Fedora, would you recommend that? If latest stable release is 
what you want, Fedora Server can provide it. If people choose some 
"stable" distribution, they usually want to limit number of changes for 
some reason.
> Alternatively, the RedHat can dedicate a support team to triage,
> answer and fix problems in these versions (taken from DistroWatch):
>
> * RHEL 7 - BIND 9.11.4 - released on 2018-07-11 - 33 patch releases behind - EOL since March 2022[2]
> * RHEL 8 - BIND 9.11.36 - released on 2021-10-27 - 1 patch release behind - EOL since March 2022[2]
> * RHEL 9 - BIND 9.16.23 - released on 2021-11-17 - 16 patch releases behind
>
> And since this is not really going to happen, I will continue people to
> use upstream sanctioned packages because that will not waste the user
> time and it will not waste the developers time.

You still can tell the user what would work on latest stable version. If 
it does not work in our version, tell them where to find more recent one 
made by you. Or that their vendor has to fix it. We have our support 
teams dedicated to our customers, but the place of our support is elsewhere.

RHEL 7 is in maintenance support 2 phase. We will fix only important 
security fixes or critical bugs. Anyone using that old distribution 
should understand what it means.

>> if the only issue in our version is unrelated to the problem investigated?
>
> There were 448 merge requests between BIND version 9.16.23 and 9.16.39,
> and 963 commits. So, how do you know that? I don't and I am certainly not
> willing to spend my already spread-thin time investigating whether any issue
> has been fixed in the last year and half, but I would be thrilled to fix any issue
> found in the latest stable BIND release. We don't make changes to BIND 9
> just because we can, there's (usually) a good reason behind every commit
> and every merge request.
>
> 1. https://git.centos.org/rpms/bind/blob/c8s/f/SOURCES
> 2. https://lists.isc.org/pipermail/bind-announce/2022-March/001210.html
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ondrej at isc.org
>
> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

I do not request you to investigate problems already fixed in your 
versions, which do not yet have fix in ours. If the error is on our 
side, okay, say it. But in this case the user has asked how to configure 
automated dnssec deployment. I am pretty sure version 9.16.0 were 
capable to do it and our 9.16.23 may be not the latest possible version, 
but can too. But I am quite confident it is able to do DNSSEC 
maintenance using policies, even if it is 500 merge requests old indeed.

We have a good reasons for our commits updating to new versions too. We 
need customer feedback stating they are missing a cool feature or bug 
fix you already have. We would have very stable bind if we never hear 
demand for updated version. Even if you do exceptional job in 
maintaining multiple major versions, still some feature changes breaks 
old deployment or require some change in configuration. I am paid to 
prevent that in our updates.

I do changes to bind in Fedora just because I can. That makes it follow 
your release cycles as close as possible. Any RHEL change needs some 
justification. It just won't update to every release you have released. 
But that does not mean it is incapable version or is unusable in general.

>> On 17. 4. 2023, at 13:57, Petr Menšík <pemensik at redhat.com> wrote:
>>
>> Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he wanted bleeding edge, he would use RHEL 9 or even Fedora. But he uses conservative package I am looking after. While it may have some known issues, it has all important fixes it needs. Can you please stop telling people to not use our packages, if the only issue in our version is unrelated to the problem investigated?
>>
>> But I admit we should update to more recent BIND 9.16 release already.
>>
>> Cheers,
>> Petr
>>
>> On 4/13/23 15:40, Ondřej Surý wrote:
>>>> On 13. 4. 2023, at 15:25, David Carvalho via bind-users <bind-users at lists.isc.org> wrote:
>>>>
>>>> I'm using 9.16.23
>>> Just don't.
>>>
>>> ISC provides packages for major linux distributions (https://www.isc.org/download/),
>>> so there's really no reason to shoot yourself into foot to use a random BIND 9
>>> snapshot provided by your distro.
>>>
>>> And while you are at it - upgrade straight to latest 9.18, your experience will be much
>>> smoother.
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ondrej at isc.org
>>>
>>> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB