Contents x
Automatic empty zones (including RFC 1918 prefixes)
  • 22 Jul 2021
  • 5 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Contents

Automatic empty zones (including RFC 1918 prefixes)

  • Updated on 22 Jul 2021
  • 5 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Article Summary

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 secondary zones to provide direction to the authoritative servers, or (less ideally) use forward zones to refer the resolution to other nameservers.
What's Next

Cookie consent

We use our own and third-party cookies to understand how you interact with our Knowledgebase. This helps us show you more relevant content and ads based on your browsing and navigation history.