Why does my recursive server have authoritative zones?

Servers that are intended solely to provide a recursive service to clients (recursion yes; and/or with allow-recursion ACLs), will almost certainly also be operating with authoritative zones loaded from which authoritative query responses are provided. The existence of these authoritative zones mean that a resolver cannot be considered to be exclusively using recursive operation with no authoritative functionality at all.

Authoritative zones loaded and served by Recursive Resolvers

Here are some examples of authoritative zones that may be loaded and used by recursive resolvers when constructing query responses to clients:

1. Automatic empty zones are authoritative primary zones automatically added to a server's zone list when named starts. This behaviour can be globally disabled using named.conf option empty-zones-enable no; in the options statement or per view, but this would not be recommended. More likely, an operator might wish to disable one or more empty zones individually by zone name using option disable-empty-zone <zone-name>;. For more information on built-in empty zones and why they are important see: Automatic empty zones (including RFC 1918 prefixes)
   
   
2. Manual empty zones are authoritative primary zones manually added to named.conf. Often these zones are defined using the same empty zone file that has been constructed in such a way that it adopts the zone name itself in order to populate the RRsets when loaded by named. There are two typical use cases: the first is to supplement or replace automatic empty zones (see above); the second is to prevent recursive clients from accessing names that the resolver operator would like to block by implementing local answers that prevent recursion from taking place. The second case is less-frequently deployed since the introduction of Response Policy Zones (see below).
   
   
3. Response Policy zones (RPZ) are defined first as normal primary or secondary zones in named.conf, but additionally are referenced in a response-policy which means that the loaded zone contents are used with a specific interpretation of the RRsets to create a response policy for responding to client queries. The authoritative and secondary zones are maintained in the same way as any other authoritative zones.
   
   
4. Mirror Zones (zones of type mirror) were created to allow a DNSSEC-validating resolver to host a local DNSSEC-validated copy of the root zone. Currently mirror zones are updated using normal secondary zone update processing, followed by a whole-zone validation process that is specific to the mirror zone implementation on BIND.
   
   
5. Built-in "chaos" zones (from which answers are provided to queries for specific server information) are loaded by default when named starts although can also be manually defined too. For an explanation of their purpose and operation see How do I restrict people from looking up the server version? ). Note that your server is primary for these built-in zones and that their content would not normally be accessible to dynamic updates, although this may no longer be the case if an administrative decision has been taken to override the built-in zones by manually declaring and managing them.