We are proud to bring you another 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 their 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. BIND 9.11.0 release notes are posted alongside the software download, and we have created a folder in the knowledge base for articles on the new 9.11 features. Below are the highlights of major enhancements in BIND and BIND tools. For any who don’t like reading, you can listen to the webinar on 9.11, with essentially the same content provided below.
In 9.11, we have added a new method of provisioning secondary servers called “Catalog Zones” has been added. 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 the Chapter 9 of the BIND 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
New RNDC commands facilitate automated zone provisioning.
- rndc showzone displays the current configuration for a specified zone
- rndc modzone can be used to reconfigure a zone, using similar syntax to rndc addzone
- 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.)
We have also have also made a significant improvement to the way we store the zones added this way.
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.
Other RNDC Improvements
RNDC can now be scripted using Python. A single RNDC connection is opened and used/re-used for the script. Formerly, if your automation issued a number of RNDC commands, a new connection was opened for each command.
A read-only option is now available. A restricted set of rndc commands are 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.
New DNSSEC Key Manager Utility
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 is a fast, flexible method for capturing and logging DNS traffic, developed by Robert Edmonds while at 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 9.11.
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 the IETF draft, Providing Minimal-Sized Responses to DNS Queries with QTYPE=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.
In BIND 9.10 we added an experimental feature we called “SIT” for Source Identity Token. Source Identity Tokens have been standardized as DNS Cookies. DNS Cookies have been updated per RFC 7873, and 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 white list 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.
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:
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 iTunes store under “ISC DIG”.
We included at least 43 contributed patches in BIND 9.11.0. Some of these will have also been included in prior maintenance releases.
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
Bradley Forschinger – Australian National University
Alexander Gall – SWITCH
Tobias Holgers- Amazon
LaMont Jones – Canonical
Jakub Luzny – RedHat
Stacey Jonathan Marshall – Solaris Software
Julian Ospald – Gentoo.org
Xose Vazquez Perez
David Ramos – Stanford University
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.
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.
New DNS Resource Record Types added in 9.11:
AVC, CDS, CDSKEY, CSYNC, NINFO, OPENPGPKEY, RKEY, TALINK, URI
The CDS and CDSKEY records are automatically created.
RFC 7344 Automating DNSSEC Delegation Trust Maintenance (informational), added CDS and CDNSKEY RRTYPEs
Child-to-Parent Synchronization in DNS, added CSYNC RRTYPE
Application Visibility and Control (AVC) record was added for a Cisco application
Using DANE to Associate OpenPGP public keys with email addresses, added OPENPGPKEY RRTYPE
RFC 7553 added The Uniform Resource Identifier (URI) DNS Resource Record