BIND 9.10 – DNSSEC, Crypto and Changes to Existing Behavior

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.

DNSSEC Improvements

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. (Note that the Thales HSM product line is now (2024) apparently part of the Entrust product line. At the same time, the PKCS#11 interface has also changed. Please consult the BIND ARM for the latest information.)

Three new options facilitate key management:

• The new “dnssec-signzone -Q” option causes dnssec-signzone, when re-signing a zone, to drop signatures from keys that are still published but are no longer active. This makes it easier to roll DNSSEC keys according to the “pre-publish key rollover” method described in RFC 4641, section 4.2.1.1.
• The new “dnssec-importkey” command allows the use of offline DNSSEC keys with automatic DNSKEY management. This allows an inline signing zone to publish or unpublish DNSKEY records on schedule even if it doesn’t have access to the corresponding private key data (arguably a bug fix).
• The new “max-zone-ttl” option enforces maximum TTLs for zones. This can simplify the process of rolling DNSSEC keys by guaranteeing that cached signatures will have expired within the specified amount of time. Loading a zone with a higher TTL will fail. DDNS updates with higher TTLs are accepted but the TTL is truncated. (Note: Currently supported for master zones only; inline-signing slaves will be added.)

Other Cryptographic Improvements

• The “rndc” command now supports new key algorithms in addition to HMAC-MD5, including HMAC-SHA1, -SHA224, -SHA256, -SHA384, and -SHA512. The -A option to rndc-confgen can be used to select the algorithm for the generated key. (The default is still HMAC-MD5; this may change in a future release.)
• Specifying the keyword “auto” instead of a salt when using “rndc signing nsec3param” will cause named to select a 64bit salt at random.

Hard-to-Classify New Features

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.

Changes to Existing Behavior

• The internal and export versions of the BIND libraries (libisc, libdns, etc) have been unified, so that when BIND 9 is built with shared libraries, other applications (e.g., ISC DHCP) can use those same libraries. Previously it was necessary to build two versions of the libraries, one for BIND 9 and another for external applications, but this is no longer the case.
• BIND 9.10 listens on IPv6 as well as IPv4 interfaces by default; it is no longer necessary to specify a “listen-on-v6” option.
• On operating systems that support routing sockets, including MacOSX, BSD and Linux, network interfaces are re-scanned automatically whenever they change. Use “automatic-interface-scan no:” to disable this feature. Use “rndc scan” to trigger an interface scan manually.
• Threads are now enabled by default on most operating systems, including Linux. Operators who were not previously using threads may see some changes in behavior.
• named now 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 named for those clients only.