Fully automated DNSSEC with BIND 9.16

[Havard Eidnes]

> 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