Knowledge Base ISC Main Website Ask a Question/Contact ISC
What has changed in the behavior of "allow-recursion" and "allow-query-cache"
Author: ISC Support Reference Number: AA-00269 Views: 79610 Created: 2011-05-03 22:08 Last Updated: 2013-04-01 23:53 100 Rating/ 1 Voters

BIND's Default Policy for Recursion

In versions of BIND prior to (and including) BIND 9.4.1, the default behavior of BIND servers was to allow recursion for all clients (unless otherwise specified.)

Because open recursion has some undesirable side-effects (such as allowing a server to be exploited by attackers targeting a victim with DNS amplification attacks) the default behavior was changed in BIND 9.4.1-P1.  Since 9.4.1-P1, unless an ACL is explicitly specified in the "allow-recursion" statement, the default access list is set to "localnets; localhost;" (in other words, the local server machine and those broadcast domains for which the server has a network interface configured at the time named is started.)

ISC no longer supports versions of BIND prior to 9.6-ESV, but some OS vendors still distribute their own BIND packages based on versions that are no longer supported.  If you are running such a version our advice is to upgrade to any currently supported version, but if you cannot, you can limit recursion by specifying the networks you wish to allow in an address match list.  Example syntax can be found in the article below.

Following is our original ISC article from the time of the change in default behavior.

There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1.

This document will attempt to clarify the change and the impact that it makes on BIND servers.

In BIND 9.3, there was no segregation of queries between cache and authoritative data.

The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver.

Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior:

  1. If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;".
  2. If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value.

Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made.

To retain the behavior prior to BIND 9.4.1-P1, the following entries would need to added to your named.conf file:

 options {
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };

However, we strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks.

The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following:

 acl "trusted" {;;

options {
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };

This example ACL includes and as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.

© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback 2
  • #
    [ Santa]: Blocking recursive DNS 2013-10-17 05:07

    Blocking recursive enquiries in bind is one thing, but it doesn't avoid the annoying log entries. I'm hoping for a way to block it in iptables.

  • #
    [Cathy Almond]: Re: Blocking recursive DNS 2013-10-17 12:20

    It's possible to configure logging to act differently for different log categories - for example to discard messages from a specific category, or only to log at a specific severity and above. Messages from different categories may also be sent to a different destination. For more details, see the BIND Administrator Reference Manual and the logging statement. (You can also temporarily update what's logged to include the catgory and level as a first step towards deciding what you do and don't want to see.)

Quick Jump Menu