I find no reason to turn off devel package creation. It can be ignored
if required, but is mandatory due to Fedora packaging guidelines.
Simplify it a bit.
Those packages were very similar in BIND 9.11. Since there is no
isc-config.sh, no significant or required reason to have them separated
exist. Keep separated libraries, but only one devel package.
DLZ modules turned built-in support into named, just like former
named-sdb package had. That was non-intentional and is disabled now.
Instead, build only dynamically loaded modules with support for various
database access.
Because pending issues with PDF regeneration, disable PDF for now.
Allow turning it on with --with DOCPDF.
It prevents building successfully on Rawhide/f33 for some reason.
Subpackage is there just as shared documentation for main package.
I want to stay in original directory, files should not move since they
were in bind package.
Documentation is not regenerated, but used as shipped by upstream.
Subpackage is there just as shared documentation for main package.
I want to stay in original directory, even most of paths have changed
since move to sphinx generated documentation.
Do not depend hard on initscript just to provide fancy colored status.
When started from systemd, it does not really matter.
Return exactly the same return code as returned by the original tool.
Do not depend hard on initscript just to provide fancy colored status.
When started from systemd, it does not really matter.
Return exactly the same return code as returned by the original tool.
Original script did not report failure as exit status. Report error if
rndc key generation failed also by exit status, not only by failed
message.
-r parameter is unsupported now, do not require it anymore.
softhsm is not provided on RHEL 8 as normal package. It is distributed
only in idm:DL1 module. If unittest or systemtest is not enabled, skip
configuring softhsm. It would not be used anyway.
Set of patches and changes, that fixes compilation of native PKCS11
support as subpackage. Moves definition of USE_PKCS11 from config.h to
Makefiles. Defaults to off and only PKCS11 subdirectories set it to
true.
Mentioned link if a file leads to XML with only checksums included.
Relation between them and included key is not obvious or specified.
Include initial digest, which is shorter and easier to validate.
Notes for BIND 9.16.2
Security Fixes
DNS rebinding protection was ineffective when BIND 9 is configured as a forwarding DNS server. Found and responsibly reported by Tobias Klein. [GL #1574]
Known Issues
We have received reports that in some circumstances, receipt of an IXFR can cause the processing of queries to slow significantly. Some of these were related to RPZ processing, which has been fixed in this release (see below). Others appear to occur where there are NSEC3-related changes (such as an operator changing the NSEC3 salt used in the hash calculation). These are being investigated. [GL #1685]
Feature Changes
The previous DNSSEC sign statistics used lots of memory. The number of keys to track is reduced to four per zone, which should be enough for 99% of all signed zones. [GL #1179]
Bug Fixes
When an RPZ policy zone was updated via zone transfer and a large number of records was deleted, named could become nonresponsive for a short period while deleted names were removed from the RPZ summary database. This database cleanup is now done incrementally over a longer period of time, reducing such delays. [GL #1447]
When trying to migrate an already-signed zone from auto-dnssec maintain to one based on dnssec-policy, the existing keys were immediately deleted and replaced with new ones. As the key rollover timing constraints were not being followed, it was possible that some clients would not have been able to validate responses until all old DNSSEC information had timed out from caches. BIND now looks at the time metadata of the existing keys and incorporates it into its DNSSEC policy operation. [GL #1706]
From Upstream Release notes:
Security Fixes
DNS rebinding protection was ineffective when BIND 9 is configured as a forwarding DNS server. Found and responsibly reported by Tobias Klein. [GL #1574]
Known Issues
We have received reports that in some circumstances, receipt of an IXFR can cause the processing of queries to slow significantly. Some of these were related to RPZ processing, which has been fixed in this release (see below). Others appear to occur where there are NSEC3-related changes (such as an operator changing the NSEC3 salt used in the hash calculation). These are being investigated. [GL #1685]