Bind 9.16.0 Release Information

/ DNS, BIND, BIND 9.16

ISC Bind 9 Logo

ISC releases BIND 9.16.0 as a stable release - Here's an inside look at what's new, changed and dropped from the latest stable version of BIND.

Bind 9.16.0 was recently released by the ISC and announced Feb. 19, 2020. The BIND 9.15 experimental branch of code has been deemed complete, stable and production worthy, making BIND 9.16 a stable branch of BIND. The ISC has adopted (as of BIND 9.13 and 9.14) an odd-unstable vs even-stable release numbering convention. This BIND 9.16.0 release is characterized using the following three (3) criteria:

  • major code refactoring
  • new features
  • performance enhancements

What's New?

NOTE: the features listed in this section are from the previous stable branch of BIND 9.14

  • A new asynchronous network communication system based on libuv is now used in the named server process for listening for inbound requests and creating responses to them. This will do two (2) things:

    1. make it easier to implement new protocol layers like DNS over TLS (future)
    2. improve performance

  • There is a new dnssec-policy option allowing the configuration of a key and signing policy (KASP) for zones. The named process can now generate new keys as needed and automatically roll both the ZSK and KSK keys.

    This allows you to create a set of DNSSEC policies such as Key, Singing, and NSEC3 handling in a single named.conf block or stanza which can then be assigned to your DNSSEC zones you have defined.

    Suppose you have a zone, you can configure it with all default KASP properties and settings as follows:

    zone "" {
       dnssec-policy "default";

    NOTE: this would pick up the default KASP policies in BIND and use those values for that zone.

    Likewise, if you have a zone called and you want to customize some or all of the KASP policies on your zone, you can assign a defined DNSSEC set of KASP policies to that zone as follows:

    zone "" {
       dnssec-policy "enterprise-settings";

    The DNSSEC policy would be build elsewhere in the named.conf file as follows:

    dnssec-policy "enterprise-settings" {
      // signatures
      signature-refresh P3D;
      signature-validity P14D;
      signature-validity-dnskey P14D;
      // Keys
      dnskey-ttl 3600;
      publish-safety PT3600S;
      require-safety PT3600S;
      keys {
         ksk key-directory lifetime P5Y 13;
         zsk key-directory lifetime 30d 13;
         csk key-directory lifetime PT0S 8 2048;
      // Zone properties
      zone-propogation-delay PT3600S;
      zone-max-ttl 24H;
      // Parent properties
      parent-propogation-delay PT24H;
      parent-registration-delay 1h;
      parent-ds-ttl 2600;

    See for more details.

  • There is a new configuration statement for managing the configuration of DNSSEC keys - trust-anchors. The previous statements for managing DNSSEC keys configurations trusted-keys and managed-keys are deprecated!

    trust-anchors - defines DNSSEC trust anchors: if used with the initial-key or initial-ds keyword, trust anchors are kept up to date using RFC 5011 trust anchor maintenance, and if used with static-key or static-ds, trust anchors are permanent.

    WARNING - when dnssec-validation is set to yes, you MUST configure trust-anchors statement(s) or there will not be DNSSEC validation. Otherwise, when set to auto, named will load and maintain root trust anchors.

    trust-anchors { string ( static-key | 
       initial-key | static-ds | initial-ds )
       quoted_string; ... };
    trust-anchors {
       "." initial-key 257 3 8  "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO

    WARNING - be careful when using trust-anchors with static-key. This has the same behavior as the recently deprecated trusted-keys statement, in that it configures permanent trust anchor(s) that will not be automatically be updated. This is not recommended usage for the root key.

  • Two (2) new keywords static-key and static-ds were introduced to the trust-anchors statement. These allow the use of trust DS formatted trust anchors instead of DNSKEY format. DS format allows trust anchors to be configured for keys that have not yet been published; This is the format used by IANA when announcing future root keys.

    NOTE: As with initial-key and static-key keywords, initial-ds will configure dynamically updated DS formatted keys using RFC 5011, and static-ds will produced a permanent trust anchor.

  • dig, mdig, and delv can now all take a +yaml option to output in detailed YAML format

    dig +yaml
    type: MESSAGE
     query_time: !!timestamp 2020-02-29T16:35:01.036Z
     response_time: !!timestamp 2020-02-29T16:35:01.569Z
     message_size: 140b
     socket_family: INET
     socket_protocol: UDP
     response_port: 53
     query_port: 58127
       opcode: QUERY
       status: NOERROR
       id: 64452
       flags: qr rd ra ad
       QUESTION: 1
       ANSWER: 1
       AUTHORITY: 2
       ADDITIONAL: 1
           version: 0
           udp: 4096
           COOKIE: e5de8b1c40bf4b507cc756235e5a92b5739cb6905faf6634 (good)
         - IN A
         - 1800 IN A
         - 3600 IN NS
         - 3600 IN NS
  • dig has a new option +[no]unexpected. By default, dig won't accept a reply from a source other than the one to which the query was initially sent to. If you wish to process replies from unexpected sources, add the +unexpected argument.

  • dig has an option to expand IPv6 addresses in AAAA records to be printed in full 128-bit notation rather than the default RFC 5982 compressed format.

    dig AAAA +expandaaaa +short
    dig AAAA +noexpandaaaa +short
  • Statistics groups display can now be toggled

What's Changed?

  • Static and managed DNSSEC keys configured for the same name, or when a static key used to configure a trust anchor for the root zone and dnssec-validation was set to the default value of auto, automatic RFC 5011 key rollovers were disabled. Support for auto and static was never intended, and now this results in a fatal named configuration error.

  • DS and CDS records are now generated with SHA-256 digests only. Previously SHA-1 and SHA-256 were used.

    NOTE: this affects the default output of dnssec-dsfromkey, the dsset files generated by dnssec-signzone, the DS records added to a zone by dnssec-signzone based on keyset files, the CDS records added to a zone by named and dnssec-signzone based on "sync" timing parameters in key files and the checks performed by dnssec-checkds.

  • named will now generate a warning if a static key is configured for the root zone!

  • An old non-default DNS Cookie security algorithm, HMAC-SHA, has been removed. A SipHash 2-4 based DNS Cookie (RFC 7873) algorithm has been added and made default. This is likely not going to have any impact on current deployed name servers.

    NOTE: if you are running an anycast group or loadbalanced group of name servers behind the same IP Address (using different versions of BIND or different name server software) make sure you use the same DNS Cookie algorithm on all servers in the group to achieve best performance results!

  • dnssec-signzone and dnssec-verify commands will now print to STDOUT. They will print to STDERR when there is a warning or error message. A new configuration option -q has been added to silence all output on standard output except for the name of the signed zone.

  • JSON-C is now the only library used for compiling BIND with JSON statistics, so use --with-json-c instead of --with-libjson

  • Autoconf now sets $prefix/etc and $prefix/var. When --prefix is not specified, --sysconfdir and --localstatedir no longer sets /etc and /var as defaults.

What's Removed?

  • dnssec-enable has been removed and no longer has any effect

  • DNSSEC Lookaside Validation (DLV) is now obsolete. The dnssec-lookaside__ option has been marked as deprecated; when used in named.conf, it will generate a warning but will otherwise be ignored.

  • The cleaning-interval previously used for setting the interval for deleting expired records has been removed.

Next Post Previous Post