Automatic empty zones (including RFC 1918 prefixes)
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;"
- 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:
Earlier versions of BIND included automatic empty zones for the following (unless those zones were already configured explictly):
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.
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.
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.