bind: Update to 9.16.27

bind: Update to 9.16.27

For details see:
https://downloads.isc.org/isc/bind9/9.16.27/doc/arm/html/notes.html#notes-for-bind-9-16-27

"Security Fixes

    The rules for acceptance of records into the cache have been
    tightened to prevent the possibility of poisoning if forwarders send
    records outside the configured bailiwick. (CVE-2021-25220)

    ISC would like to thank Xiang Li, Baojun Liu, and Chaoyi Lu from
    Network and Information Security Lab, Tsinghua University, and
    Changgen Zou from Qi An Xin Group Corp. for bringing this
    vulnerability to our attention. [GL #2950]

    TCP connections with keep-response-order enabled could leave the TCP
    sockets in the CLOSE_WAIT state when the client did not properly
    shut down the connection. (CVE-2022-0396) [GL #3112]

Feature Changes

    DEBUG(1)-level messages were added when starting and ending the BIND
    9 task-exclusive mode that stops normal DNS operation (e.g. for
    reconfiguration, interface scans, and other events that require
    exclusive access to a shared resource). [GL #3137]

Bug Fixes

    The max-transfer-time-out and max-transfer-idle-out options were not
    implemented when the BIND 9 networking stack was refactored in 9.16.
    The missing functionality has been re-implemented and outgoing zone
    transfers now time out properly when not progressing. [GL #1897]

    TCP connections could hang indefinitely if the other party did not
    read sent data, causing the TCP write buffers to fill. This has been
    fixed by adding a “write” timer. Connections that are hung while
    writing now time out after the tcp-idle-timeout period has elapsed.
    [GL #3132]

    The statistics counter representing the current number of clients
    awaiting recursive resolution results (RecursClients) could
    be miscalculated in certain resolution scenarios, potentially
    causing the value of the counter to drop below zero. This has been
    fixed. [GL #3147]"

Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>