Comparative Performance Results of BIND Versions - March 2020
Now that the latest version of BIND 9 has been released, it is worthwhile to look at the performance enhancements that have taken place over the past couple of years.Read post
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.
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.
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.
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.)
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.
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.
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.
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 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.
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, 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.
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.
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:
valuesets the DSCP code point in outgoing query packets.
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.
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:
Plus individual patches from:
We thank all the patch contributors, as well as the many people who reported issues that we were able to fix in 9.11.
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:
The CDS and CDSKEY records are automatically created.
What's New from ISC