Knowledge Base ISC Main Website Ask a Question/Contact ISC
Automatic empty zones (including RFC 1918 prefixes)
Author: ISC Support Reference Number: AA-00800 Views: 15894 Created: 2012-09-26 17:07 Last Updated: 2015-03-27 09:18 0 Rating/ Voters

BIND provides a number of empty zones that are automatically configured and loaded (for each view) when named starts.  The purpose of these zones is to prevent recursive servers from sending meaningless queries to Internet servers that cannot handle them (thus creating delays and SERVFAIL responses to clients who query for them).  These empty zones ensure that immediate and authoritative NXDOMAIN responses are returned instead.

The configuration option empty-zones-enable controls whether or not empty zones are created, whilst the option disable-empty-zone can be used in addition to disable one or more empty zones from the list of default prefixes that would be used.

For a view that has recursion enabled, the default is "empty-zones-enable yes;"

For a view that has recursion disabled, the default is "empty-zones-enable no;"

Empty zones will not replace explicitly configured zones.
When creating an empty zone, named first checks that the zone is not already in use and does not create one under the following conditions:

  • If a zone declaration for that exact prefix is already present in named.conf
  • When forwarding with "forward only;" would otherwise apply to queries for names in that zone as a result of a global directive or options specified in a parent zone.   For example, the empty zone for 10.in-addr.arpa will not be created if there is global forwarding with "forward-only;", or if there is a forward-only zone declaration for arpa or in-addr.arpa.  (Forwarding with "forward first;" does not block empty zone creation because, unlike "forward only", it does not prevent recursive resolution entirely)

BIND 9.6-ESV-R5, 9.7.4, 9.8.1 and 9.9.0 introduced empty-zone support for all prefixes listed in RFC 6303, thus adding to the list of empty zones all those with RFC 1918 prefixes.  This is a good thing as most users of RFC 1918 address space do not configure the corresponding IN-ADDR.ARPA zones and leak queries to the internet as a whole. This has required others to deploy sacrificial servers to shift the queries away from the IN-ADDR.ARPA servers.

Although the default setting is 'yes', users of BIND 9.6-ESV-R5, 9.7.4, 9.8.1 (and superseding revisions and minor versions) will not see the new RFC 1918 empty zones in addition to the existing automatic empty zones unless they explicitly configure empty-zones-enable yes;

Users of BIND 9.9 and above will see the new RFC 1918 empty zones both when empty-zones-enable is unspecified (defaults to yes), and when it is explicitly set to 'yes'.

The additional RFC 1918 empty zones are:

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA

Earlier versions of BIND included automatic empty zones for the following (unless those zones were already configured explictly):

0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA

Those upgrading to BIND 9.9 and newer may find that they now have RFC 1918 empty zones included that they didn't have on earlier versions (9.8 and earlier)

The treatment of the newly-introduced RFC 1918 automatic empty zones is different from 9.9.0 onwards.  Those undertaking a major version upgrade (from e.g. 9.8.x or earlier) could experience problems with RFC1918 zones that they are using internally in their organization.

In BIND 9.6-ESV-R5, 9.7.4, 9.8.1 (and newer versions of 9.6-ESV, 9.7 and 9.8 that supersede them), all of the empty zones except the new RFC 1918 empty zones are added automatically when empty-zones-enable has not been declared as an option.  These new RFC 1918 empty zones will not be loaded unless named.conf explicitly includes option empty-zones-enable yes; (i.e, the default is 'yes', but not fully 'yes'.  This was done to minimize the likelihood of unexpected behaviour being encountered by users following small incremental upgrades within the same major version.)

From BIND 9.9.0, the new RFC 1918 empty zones have equal status with those in the earlier set and are all included by default.

When upgrading across major versions (e.g. from BIND 9.8 to 9.9) administrators are urged to check the release notes for at least the 9.x.0 and 9.x.1 releases for differences in features and functionality.  See Which version of BIND do I want to download and install? for further guidance on choosing an upgrade path.

Prior to BIND 9.9.0, the warning message below may be encountered when named is starting:

Warning: 'empty-zones-enable/disable-empty-zone' not set:
disabling RFC 1918 empty zones

This is emitted when the empty-zones-enable option is not set and when named does not encounter any RFC 1918 zones in named.conf - either explicitly configured or explicitly disabled as an empty zone via option disable-empty-zone (in which case the default is to disable the RFC 1918 empty zones).  Its purpose is to highlight to the administrator that these empty zones are now available to be enabled, but were not included by default.

The warning is not generated if any RFC 1918 zones are encountered since it's assumed that the administrator is already aware of and using these zones and would not want or expect named's behaviour to change on a minor BIND version or ESV revision upgrade.

If you are using RFC 1918 addresses other configuration considerations apply

Installations that are using RFC 1918 zones should already be aware of the potential impact of leakage of queries and be responsible for configuring their servers to be authoritative for them so as to handle any PTR queries internally.

However, from BIND 9.9.0 onwards (and versions of BIND that include RFC 1918 empty zones with empty-zones-enable), by default, all nameservers (including your recursive servers) will be authoritative for these zones (and subdomains of them) unless they're either configured explicitly or have that automatic zone disabled using the disable-empty-zone option.

  • Reverse (PTR) lookups for addresses in these address ranges will be responded to with NXDOMAIN (unless the server is itself authoritative for a subdomain and can serve a different answer).
  • Forwarding with option "forward first;" will not be followed (this is because authoritative answers will always be given in preference to forwarding).
  • Forward zones for resolution of subdomains of RFC 1918 zones will no longer work.  This is because even though these are declared explicitly, forwarding is a form of recursion.   Recursion (i.e. sending a query to another server to get an answer) will not happen if the server is already authoritative for the parent zone and has no delegations from it.

Although this will be effective as a workaround, administrators are urged not to just specify empty-zones-enable no;

It is much better to use one or more disable-empty-zone option declarations to disable only the RFC 1918 empty zones that are in use internally. 

At the same time, administrators should also ensure that authoritative zones are configured in such a way that all answers are handled within the internal DNS topology.  To ensure that resolution works correctly, recursive servers that would normally communicate with the Internet servers authoritative for IN-ADDR.ARPA and IP6.ARPA (and below) will either need to be authoritative for the internal RFC 1918 zone(s) themselves, use, stub or slave zones to provide direction to the authoritative servers, or (less ideally) use forward zones to refer the resolution to other nameservers.



© 2001-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

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 6
  • #
    [ Scott]: I Got Burned Too 2015-02-04 17:24

    I agree with John Hilgart. We had exactly same problem. The statement "The treatment of the newly-introduced RFC 1918 automatic empty zones is subtly different on 9.9" isn't so subtle. Doing a minor upgrade and then having all your reverse 1918 zones error out is not something you would normally expect.

  • #
    [Cathy Almond]: Re: I Got Burned Too 2015-03-27 09:33

    Hi Scott. Sorry that you also hit problems upgrading to BIND 9.9 from an earlier major version. I've removed the word 'subtle' from the note. But I'm not sure what else we could have done here? It was important to include the newly-added RFC1918 zones (in the best interests of Internet housekeeping). We deliberately didn't make that an automatic new feature in earlier minor revisions (recognising that changes from 9.x.y to 9.x.y+1 shouldn't introduce significant changes in functionality that could surprise administrators), but we did provide the possibility to choose to turn on the new empty zones. The full change to the automatic behavior was deferred until it could be introduced as a new feature in a new major release (9.9.0).

  • #
    [John Hilgart]: I got burned 2014-06-25 14:43

    OK. I'll admit it. I got totally burned by this when I did that upgrade from 9.8 to 9.9. I've done upgrades like that for years without issue. This time I had all my RFC1918 queries clobbered on my cache-only server.
    And a Google search is not that productive, by the way. I will mention the problem in my blog to guide others a little more quickly to the solution.

  • #
    [Admin]: Re: I got burned 2014-07-02 20:40

    Hi John, sorry to hear that. Generally of course we recommend that you read the release notes, especially with a minor version (9.8-9.9, 9.9-9.10) upgrade, but I know how it goes sometimes. We have a few articles about upgrade procedures, but perhaps we can make them easier to find? As a result of your feedback, those are now under review. Thank you for the comment and for using BIND.

  • #
    [Guodong Ding]: A Sample solution 2014-01-20 11:32

    Add those lines to "option" section, then it will works!
    empty-zones-enable no;
    disable-empty-zone ".";

  • #
    [Cathy Almond]: Re: A Sample solution 2014-01-28 13:10

    We do not recommend disabling empty zones entirely unless you are configuring all the zones explicitly in this address space yourself. The purpose of these zones is to prevent recursive servers from sending meaningless queries to Internet servers that cannot handle them (thus creating delays and SERVFAIL responses to clients who query for them). These empty zones ensure that immediate and authoritative NXDOMAIN responses are returned instead.

    If you are encountering a particular problem due to automatic empty zones, then it is most likely that you can resolve it by using one or more disable-empty-zone option declarations to disable only the empty zones that are in use by your own internal servers.

Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu