Release 9.11 Adds Provisioning Options for DNS Authoritative Services

We are proud to bring you another great version of BIND, 9.11.0. We have added many new features, updated our support for DNS standards, improved efficiency in a number of areas, and made provisioning and DNSSEC operations more convenient.

BIND users now have three supported versions to choose from: 9.9, 9.10 and now, 9.11. We recommend that administrators run one of our older, stable branches, such as a 9.9- or 9.10-based release on larger-scale critical production systems, while testing the new 9.11 branch until the second maintenance release. Version 9.9 is our current Extended Support Version, with support guaranteed through December 2017. If you are wondering what the differences are between these releases, check the BIND 9 Significant Features Matrix.

BIND 9.11.0 release notes are posted alongside the software download, and you can find many articles in our Knowledgebase about the new 9.11 features. We posted the recording of our webinar on the new features in our YouTube channel. Below are the highlights of major enhancements in BIND and BIND tools.

Catalog Zones

In 9.11, we have added a new method of provisioning secondary servers called “Catalog Zones.” This is an implementation of draft-muks-dnsop-dns-catalog-zones. This feature will automatically propagate new zones added to the primary master to the secondary servers, or remove zones deleted from the primary master, eliminating the need for separate scripts to do this.

A catalog zone is a regular DNS zone which contains a list of “member zones,” along with the configuration options for each of those zones. When a server is configured to use a catalog zone, all the zones listed in the catalog zone are added to the local server as slave zones. When the catalog zone is updated (e.g. by adding or removing zones, or changing configuration options for existing zones), those changes will be put into effect. Since the catalog zone is itself a DNS zone, this means configuration changes can be propagated to slaves using the standard AXFR/IXFR update mechanism.

This feature should be considered experimental. Example catalog zone configurations can be found in Chapter 9 of the BIND 9 Administrator Reference Manual. For an overview of how to configure catalog zones, read A Short Introduction to Catalog Zones. JP Mens tested this feature prior to release and wrote a blog post on it.

Addzone/Delzone Provisioning Improvements

We have added some new RNDC commands to facilitate automating zone provisioning, and have also made a significant improvement to the way we store the zones added this way.

• rndc delzone can now be applied to zones which were configured in named.conf; it is no longer restricted to zones which were added by rndc addzone. (Note, however, that this does not edit named.conf; the zone must be removed from the configuration or it will return when named is restarted or reloaded.)
• When BIND is built with the lmdb library (Lightning Memory-Mapped Database), named will store the configuration information for zones that are added via rndc addzone in a database, rather than in a flat “NZF” file. This dramatically improves performance for rndc delzone and rndc modzone: deleting or changing the contents of a database is much faster than rewriting a text file.
• rndc modzone can be used to reconfigure a zone, using similar syntax to rndc addzone.

Other RNDC Improvements

RNDC can now be scripted using Python. A single RNDC connection is opened and used/re-used for the script.

A read-only option is now available. A restricted set of rndc commands is allowed, which can report information from named, but cannot reconfigure or stop the server. By default, the control channel access is not restricted to these read-only operations.

DNSSEC Key Manager

Best practices for DNSSEC implementation require regular key rollovers. This can be a maintenance burden and is now easily automated with a new utility.

dnssec-keymgr is meant to run unattended (e.g., under cron). It reads a policy definition file (default: /etc/dnssec.policy) and creates or updates DNSSEC keys as necessary to ensure that a zone’s keys match the defined policy for that zone. New keys are created whenever necessary to ensure rollovers occur correctly. Existing keys’ timing metadata is adjusted as needed to set the correct rollover period, prepublication interval, etc. If the configured policy changes, keys are corrected automatically. See the dnssec-keymgr man page for full details.

Many thanks to Sebastián Castro for his assistance in developing this tool at the IETF 95 Hackathon in Buenos Aires, April 2016. We also include a contributed python script, kasp2policy, to create a DNSSEC policy file from an OpenDNSSEC KASP XML file.

Parent-Child Updating (DNSSEC Information)

Another task associated with the DNSSEC KSK rollover is updating the parent zone with the new DS record, or DSKEY record. Today this is usually accomplished by manually filling in a web form. After much discussion in the industry, the consensus seems to be that the most flexible automated way to do this with adequate security, is to publish the information in the child zone, using DNSSEC to ensure the integrity of the information.

Following RFC 7344 Automating DNSSEC Delegation Trust Maintenance, two new resource records, CDS and CDSKEY, are created and populated automatically for DNSSEC-signed zones, on the server that is authoritative for those zones. These “child” records can be looked up by the parent, enabling the parent to update itself.

Negative Trust Anchors

When a DNSSEC signed zone fails to validate, sometimes the problem is due to a misconfiguration or maintenance problem (such as expired signatures) in the authoritative system.

The rndc nta command can now be used to set a “negative trust anchor” (NTA) on a resolver, disabling DNSSEC validation for a specific domain; this can be used when responses from a domain are known to be failing validation due to administrative error rather than because of a spoofing attack. NTAs are strictly temporary; by default they expire after one hour, but can be configured to last up to one week.

In addition, named will periodically test to see whether data below an NTA can now be validated, removing the NTA if it is no longer needed. This feature can be disabled.

DNSTAP

Dnstap is a fast, flexible method for capturing and logging DNS traffic, developed by Robert Edmonds at Farsight Security, Inc. Dnstap is supported by several open-source DNS servers, now including BIND.

Using dnstap enables capturing both query and response logs, with a reduced impact on the overall throughput of the BIND server than native BIND logging.

Messages may be logged to a file or to a unix socket. Support for log file rotation will depend on which option you choose. There is a new RNDC command for “manually” rotating the log file included in BIND 9.11.

A new utility dnstap-read has been added to allow dnstap data to be presented in a human-readable format. For more information, see Using DNSTAP with BIND.

Minimal Response to ANY Queries

Queries for ANY records are a possible abuse mechanism because they typically extract a response much larger than the query.

The new minimal-any option reduces the size of answers to UDP queries for type ANY by implementing one of the strategies in “draft-ietf-dnsop-refuse-any”: returning a single arbitrarily-selected RRset that matches the query name rather than returning all of the matching RRsets.

minimal-responses takes two arguments: no-auth suppresses populating the authority section but not the additional section; no-auth-recursive does the same but only when answering recursive queries.

Thanks to Tony Finch for the contribution.

DNS Cookies

DNS Cookies, per RFC 7873, are now enabled by default. Cookies are exchanged between client and server to provide IP address identity, helping to prevent attacks using forged IP addresses. Servers enforcing cookies are less susceptible to being used as an effective attack vector for DNS DDOS attacks.

When sending a query, a BIND resolver will send a cookie, and when receiving a query, a BIND authority will look for a cookie. If a valid cookie is present with the query, the BIND authority will whitelist that client for rate limiting. This has the potential to make rate limiting more effective overall because it can focus on less-trusted traffic.

New commands include require-server-cookie and send-cookie (both default to ON in 9.11.0). Setting a cookie-secret will enable a cluster of BIND servers to share cookies. For more information, including the potential for DNS cookies to expose EDNS compatibility problems, read DNS Cookies in BIND 9.

Dynamic Database (DynDB) Interface

DynDB is a new interface for loading zone data from an external database, developed by RedHat for the FreeIPA project. (Thanks to Adam Tkac and Petr Spacek of RedHat for the contribution.)

DynDB fully implements and extends the database API used natively by BIND. DynDB modules load data from an external data source (e.g. a database), then serve it with the same performance and functionality as conventional BIND zones, enabling you to take advantage of database features not available in BIND, such as multi-master replication. This feature provides a database backend alternative to the BIND DLZ (dynamically-loaded zones). DynDB is faster than DLZ and supports features which DLZ does not support (in-line signing).

The software posted at https://github.com/pspacek/bind-dyndb-ldap will be updated to version 11.0, and that version will be interoperable with this feature, providing an LDAP database backend for BIND.

Dig Enhancements

The new mdig command is a version of dig that sends multiple pipelined queries and then waits for responses, instead of sending one query and waiting the response before sending the next. There are also number of new dig options:

• dig +ednsopt sets arbitrary EDNS options in DNS requests.
• dig +ednsflags sets yet-to-be-defined EDNS flags in DNS requests.
• dig +[no]ednsnegotiation enables/disables EDNS version negotiation.
• dig +header-only sends queries without a question section.
• dig +ttlunits causes dig to print TTL values with time-unit suffixes: w, d, h, m, s for weeks, days, hours, minutes, and seconds.
• dig +zflag sets the last unassigned DNS header flag bit. This bit is normally zero.
• dig +dscp=value sets the DSCP code point in outgoing query packets.
• dig +mapped determines if mapped IPv4 addresses can be used.

DIG users may also be interested in the new, free DIG app for IOS, based on BIND 9.10.4 (currently). Find it in the App Store.

Contributed Patches

We included at least 43 contributed patches in BIND 9.11.0. Some of these will have also been included in prior maintenance releases. Here are our top contributors:

• Tony Finch - Cambridge University (12 patches)
• Tomas Hozza - RedHat (4 patches)
• Petr Spacek - RedHat (3 patches)
• Bill Parker - (3 patches)
• Timothe Litt - (2 patches)

Plus individual patches from:

• Thomas Anderson - CalTech
• BlueCat Networks
• Bradley Forschinger - Australian National University
• Alexander Gall - SWITCH
• Tobias Holgers- Amazon
• InfoBlox
• LaMont Jones - Canonical
• Jakub Luzny - RedHat
• Stacey Jonathan Marshall - Solaris Software
• Julian Ospald - Gentoo.org
• Armin Pech
• Xose Vazquez Perez
• David Ramos - Stanford University
• Tom Sawyer
• Brad Smith
• Dr. Jeffry A. Spain - Cincinnati Country Day School
• Daniel Stirnimann - SWITCH
• Adam Tkac - RedHat
• Holger Zuleger - HZNET.DE

We thank all the patch contributors, as well as the many people who reported issues that we were able to fix in 9.11.

Standards Support

We try to keep up with the new Internet standards for DNS. In this release we have added support for RFC 7873, Domain Name System (DNS) Cookies. We wrote a draft standard for Catalog Zones (DRAFT), which is still under review by the standards community.

New DNS Resource Record Types added in 9.11:

• AVC, CDS, CDSKEY, CSYNC, NINFO, OPENPGPKEY, RKEY, SMIMEA, TALINK, URI

The CDS and CDSKEY records are automatically created.

References:

• RFC 7344 Automating DNSSEC Delegation Trust Maintenance (informational), added CDS and CDNSKEY RRTYPEs
• Child-to-Parent Synchronization in DNS, added CSYNC RRTYPE
• Using Secure DNS to Associate Certificates with Domain Names for S/MIME, added SMIMEA RRTYPE
• Application Visibility and Control (AVC) RRTYPE
• Using DANE to Associate OpenPGP public keys with email addresses, added OPENPGPKEY RRTYPE
• The Uniform Resource Identifier (URI) DNS Resource Record, added URI RRTYPE