Comparative Performance Results of BIND Versions - September 2023
We are only one quarter away from producing the next stable branch of BIND, and from ending maintenance of BIND 9.Read post
This is the last of three blog posts introducing the new features in BIND 9.10. With BIND 9.10 we continue improving DNSSEC support. For the complete list of new features, see the BIND 9.10 Release Notes.
PKCS#11 API for direct control of HSM. A new compile-time option (“configure –enable-native-pkcs11”) allows the BIND 9 cryptography functions to use the PKCS#11 API natively, so that BIND can drive a cryptographic hardware service module directly instead of using a modified OpenSSL as an intermediary. This has been tested with the Thales nShield HSM, and with SoftHSMv2 from the Open DNSSEC project. (See the “Thales ISC Solution Brief” from Thales.) Information about this option and how to use it is in the BIND 9.10 ARM. We are planning a joint webinar with Thales on the topic in June, 2014.
Three new options facilitate key management:
namedto select a 64bit salt at random.
Multiple DLZ databases can now be configured in the same server. Prior to release 9.10, BIND supported only one DLZ database; now you can have a DLZ module for redirect zones, while keeping the DLZ module you already have. Details of how to configure and use this expanded capability as part of an expansion of NXDOMAIN redirection can be found in NXDOMAIN Redirection Using DLZ in BIND 9.10 and later.
RPZ now allows response policies to be configured based on the IP address of the client.
The Windows installer now places files in the Program Files area rather than system services. Several features previously unavailable on Windows are now available, including “delv” and the “export library” APIs including libirs. The Python tools “dnssec-coverage” and “dnssec-checds” can now be enabled on Windows via “Configure”, but are not included in the installation zip files. All versions of Visual Studio up to 2013 are now supported, and support has been added for 64-bit builds.
Source Identity Token (SIT), similar to DNS Cookies (invented by Donald Eastlake and described in draft-eastlake-dnsext-cookies-04); these are designed to enable clients to detect off-path spoofed responses, and to enable servers to detect spoofed-source queries. Servers can be configured to send smaller responses to clients that have not identified themselves using a SIT option, reducing the effectiveness of amplification attacks. RRL processing has also been updated; clients proven to be legitimate via SIT are not subject to rate limiting. This feature is experimental in BIND 9.10 as the draft is updated.
Finally, in addition to all the new features and performance enhancements, there are some changes in existing features that you need to know about.
namednow preserves the capitalization of names when responding to queries. For instance, a query for “example.com” may be answered with “example.COM” if the name was configured that way in the zone file. Some clients have a bug causing them to depend on the older behavior. Previously the case of the answer always matched the case of the query, rather than the case of the name configured in the DNS. Such clients can now be specified in the new “no-case-compress” ACL; this will restore the older behavior of
namedfor those clients only.
What's New from ISC