Fully automated DNSSEC with BIND 9.16
Havard Eidnes
he at uninett.no
Tue Apr 18 07:20:13 UTC 2023
> You do not have to sift through lists.
That depends entirely what one wants to do. I see a couple of
scenarios where that may be required:
1) Let's say someone has flagged to you as a BIND administrator that
your BIND installatin is susceptible to CVE-2022-3924. This
could be done via an "external scan" and based on the BIND
version returned (if your BIND is configured to reveal such
details), or via other means. How do you as an administrator
figure out if the version you actually run has the fix for this
CVE included?
From the BIND change log, I can see
--- 9.16.37 released ---
6067. [security] Fix serve-stale crash when recursive clients soft quota
is reached. (CVE-2022-3924) [GL #3619]
and if I run straight "upstream" code, it's fairly straight-
forward to upgrade to this version, modulo, of course, the fact
that this involves building it from source.
On the other hand, looking at a version produced by a package
maintainer (RedHat, Debian, ...), and where the package
maintainer insists on sticking with whatever base version they
started from (strictly based on timing, in all probability) and
selectively applying patches, it will be much harder to figure
out whether the fix is actually included. And ... if the fix is
indeed included, you'll as administrator in all probability have
to mark the issue as "false positive" after having assured
yourself that the fix is included. However, getting to this
assurance can be quite a bit of work.
2) You will end up with a somewhat similar scenario for
non-security-related functionality fixes -- you may hit a
problem which has been fixed upstream since your distributor
forked off BIND, and you may be able to find the entry for the
fix in BIND's upstream change log, but figuring out if that
fix is indeed included in the code you run will make it
necessary to rummage through the "patch list" of the
package administrator.
> We provide quite detailed git branch with each change we
> make. It has references to bugs related too. I admit changes
> listed in release notes of bind9 releases are nicer. But we do
> not hide what and why we do changes, publish them quite nice
> way for c9s [1]. It would be the same c8s as well soon.
>
> For important changes they are mentioned in release notes of the minor
> release. But I admit we do not mention explicitly each bug we fix the
> way ISC does. It would make our documentation unreadable.
>
> In any case, even if we fall behind a couple of releases, any our
> packages of bind 9.16 are capable of automated DNSSEC deployment just
> fine. Sure, even we do not support it for RHEL7 or older.
>
> [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s
I certainly do appreciate that this is a considerable effort, and
that you do this as well as you can with all good intentions. Now,
even though the change log is available as stated (which is good, of
course) does not necessarily make it easy to find. And ... solving
the above two issues still requires a detailed sift through the
lists.
Regards,
- Håvard
More information about the bind-users
mailing list