Response-rate limiting (DNS RRL) is now available by default
ISC introduced the Response Rate Limiter into earlier versions of BIND as a configurable option. It was not automatically available. RRL has proven to be so valuable and effective that it is now included in the default software-build configuration, which means that you can use RRL without having to configure and create a custom version of BIND. Instructions for using RRL are in Using the Response Rate Limiting Feature and (in somewhat more detail) in the BIND 9.10 ARM.
New format option "map" for zone files stored on disk, allowing substantially faster zone loading
DNS zones are stored in the host server's file system. BIND reads those zone files to acquire its in-memory zone information. In earlier versions of BIND you could specify that a slave zone file (acquired via a zone transfer from a master server) be stored in text format or raw format. BIND 9.10 introduces a third choice, "map" format. A map-format zone file is an exact mirror of the in-memory data structure used by BIND to represent the zone while BIND is running. It can therefore be read quickly, since it needs no further processing. Consult the BIND 9.10 Administrator's Reference Manual (ARM) to learn when using map format would be a good idea, when it would be a bad idea, and the details of how to set up and use map-format zone files. See Using the 'map' zone file format in BIND for a summary of appropriate and inappropriate usage of map-format zone files.
Substantial improvements in Response Policy Zone (RPZ) performance
Updates to the RPZ mechanism that add features and improve performance were contributed to BIND by Vernon Schryver and Paul Vixie. In BIND 9.10, up to 32 response-policy zones can be used with very little performance impact. BIND 9.10 RPZ also supports drop policies and triggers based on the client's IP address. See DNSRPZ performance and scaleability when using multiple RPZ zones for more information about this update and for a refresher on the RPZ mechanism and the impact of its use.
Early prefetch of about-to-expire cached resource records
DNS resource records that are received by a resolver are kept in its cache until they expire. BIND 9.10 now offers a "prefetch" option, by which it will detect records that are about to expire and fetch a new copy before actual expiration. This will improve the performance delivered to end users for resolving names that have short expiration times. See Early refresh of cache records (cache prefetch) in BIND for more information about this new "prefetch" option.
Access Control Lists (ACLs) can now specify addresses geographically
BIND 9 access control lists are used to limit access to various server functions according to the IP address of the requestor of that access. BIND 9.10 is able to use data from MaxMind GeoIP databases to achieve restrictions based on the (presumed) geographic location of that address. The ACL itself is still address-based, but the GeoIP-based specification mechanisms can easily populate an ACL with addresses in a certain geographic location. This capability was derived from code contributed by Ken Brownfield. An interesting use of geographic ACLs is to offer different BIND Views to clients in different geographic locations. See Using the GeoIP Features in BIND 9.10 for more information about GeoIP features in BIND 9.10.
XML statistics reported from BIND refocused on "new" format.
BIND can provide statistics in either XML or JSON formats. Previous versions of BIND had offered the option of XML statistics in regular (v2) or new (v3) format. After incorporating user feedback, BIND 9.10 offers only v3 format but offers it in the default version (without needing to custom-build a BIND with statistics enabled).
The statistics channel now also includes many new statistics, including stats for the resolver, cache, address database, dispatch manager, and task manager, which can be used to monitor server health. New URLs have been added to the statistics channel to provide broken-out subgroups of statistics so as to reduce parsing complexity. The XSL stylesheet that enables interpretation of XML statistics can now be cached by the browser.
Improvement to options for software builds
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.
New configuration option enables 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. Information about this option and how to use it is in the BIND 9.10 ARM.
IPv6 now enabled by default
BIND 9.10 listens on IPv6 as well as IPv4 interfaces by default; it is no longer necessary to build with a "listen-on-v6" configuration option.
Expansion of Dynamically Loadable Zones (DLZ) capability
Multiple DLZ databases can now be configured in the same server. Individual zones, of type "master" or "redirect", can be configured to be served from a specific DLZ database. Details of how to configure and use this expanded capability can be found in NXDOMAIN Redirection Using DLZ in BIND 9.10 and later. The ability to use multiple DLZ databases was added to DLZ as part of an expansion of NXDOMAIN redirection, so the focus of that KB article is on NXDOMAIN redirection.
Improvements to EDNS processing
EDNS processing in BIND 9.10 has been updated to better track remote server capabilities when handling recursive queries - this should both improve recursive performance when handling multiple authoritative servers and situations where connectivity is intermittent or limited by older or misconfigured in-path equipment. You can find more information about the updated processing algorithms and server status records in Testing authoritative server support for EDNS and large UDP buffer sizes in BIND 9.10.
Updates and improvement to BIND tools
Every release of BIND includes an updated set of manual pages for the various BIND tools. Those manual pages are current for the release in which they are included. Appendix B of the BIND ARM contains a copy of those pages. Below we identify the updates and changes made to BIND tools for BIND 9.10.
BIND 9.10 contains a new tool called "delv". It is very much like "dig", except that it has a much deeper understanding of DNSSEC. See Eleven, twelve; dig and delv: BIND 9.10.
The "rndc" control channel now supports more signing algorithms; previously it had only supported HMAC-MD5. (We expect to switch to HMAC-SHA256 as the default signing algorithm in a future release.)
The new "rndc zonestatus" command reports information about a specified zone, including configuration details, last load time, serial number, and when the next automatic zone maintenance events are scheduled.
The new "named-checkconf -px" option will print the contents of configuration files with shared secrets obscured. This makes it easier to share your server configuration -- for example, when reporting a bug -- without revealing private information.
named-checkzone and named-compilezone
The "named-checkzone" and "named-compilezone" commands can now read journal files, allowing them to read the current state of a dynamic zone without freezing it and syncing its journal file first.
The new "named-rrchecker" tool can be used to verify the syntactic correctness of individual resource records, or to convert them into a canonical format so that a newly defined record type can be loaded into an older name server that doesn't recognize it. See Introducing the named-rrchecker tool.
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.
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 220.127.116.11.