Why does my authoritative server make recursive queries?

Servers that do not accept recursive queries because they have recursion fully disabled (recursion no;), may nevertheless still be observed sending queries to other servers and as a result create and maintain a resolver cache for its own use. These queries are also counted in the resolver statistics (although there will be no impact on the client statistics because the queries it makes are independent of and not directly related to any client queries received that it is handling).

Causes of recursion by an authoritative-only server

Here are some scenarios that can cause an authoritative-only server to make its own queries (i.e. appear to be acting as a recursive resolver):

1. Authoritative zones may contain NS records for servers whose addresses are unknown to this server - that is, the names of the other servers are not within any zones that this server has authority for. In this instance, if the server needs to send notifies following zone content updates, it will be obliged to send A and AAAA queries for the names of the nameservers, and it invokes the recursive functionality of named to do this (creating either a small cache in the default view if no views have been defined, or in the view that this authoritative zone has been defined within)

2. DNSSEC Trust Anchor Maintenance involves sending DNSKEY queries to zones (typically the root zone) for which your server has loaded automatically-managed keys. For more details about this, see 9.16 DNSSEC validation automatic trust anchor management.
   By default, BIND provides built-in trust anchors that are loaded when no trust anchors have been configured explicitly in named.conf and when option dnssec-validation is set to auto, which is the new default since BIND 9.13.

3. Trust Anchor Telemetry is a feature whereby named sends a specific type of query that zone administrators can use to learn how their key rollovers are progressing and how many resolvers have updated the trusted keys they are using for this zone (usually the root zone). The updates may have been made manually or automatically (see section 2. above). For more information regarding Trust Anchor Telemetry, see: BIND Trust Anchor Telemetry in BIND 9.9.10, 9.10.5 and 9.11.0.

4. Negative Trust Anchors are a means by which a DNSSEC-validating resolver operator can temporarily disable DNSSEC validation for a zone when it is confirmed that the zone's DNSSEC has been misconfigured or mismanaged. NTAs are added using the rndc nta command specifying the zone to be exempted from DNSSEC-validation. After a Negative Trust Anchor (NTA) has been added, BIND performs periodic checks to see if it is still necessary (various named.conf and rndc options can be used to control both the period of validity of Negative Trust Anchors and the polling interval).

Authoritative-only server functions that do not use recursion

For clarity, here are three scenarios that do not use recursion, even though the observer of the operation or configuration of an authoritative-only server might anticipate that they would.

1. Authoritative-only servers do send some queries as part of carrying out zone maintenance. SOA queries sent to the servers listed in the primaries clause of secondary zone definitions do not use named's resolver code, and the query responses are not placed in a resolver cache. No DNSSEC-validation will place against these query responses. The processes that make SOA queries, review query response content, and go on to query other primaries and/or request XFRs are independent of resolver activity and have their own authentication mechanisms.

2. Dynamic update forwarding may take place when a server that is secondary for a zone receives a dynamic update that it might, if configured to do, send onward to a primary authoritative server. Intuitively one might anticipate that named would use the secondary zone's SOA MNAME field and, therefore might need to resolve it. However, update-forwarding uses the zone's configured primaries list instead. See option allow-update-forwarding for details on how update-forwarding can be enabled.

3. Populating and maintaining a mirror zone (usually mirrored root) uses neither recursion nor resolver-based DNSSEC-validation. Note, however, that the primary use case for a zone of type mirror is to make a DNSSEC-validated copy of the root zone available at all times for resolver use, so it would be unlikely that an operator would need to configure a zone of type mirror on an authoritative-only server. Mirror zones cannot be used in a view that does not have recursion enabled.

The following are configurations that do require the use of recursion when handling client queries

1. Global and per-view forwarding - the forwarder configuration is applied to redirect the recursive queries at the point it becomes necessary to 'do recursion'.
2. Forward zones - which operate on a per-zone basis similar to global and per-view forwarding).
3. Stub zones for which named uses the secondary zone logic to obtain the minimal NS and SOA RRs for the zone, but thereafter will recurse on behalf of clients for zone contents using the learned authoritative servers.
4. Zones of type static-stub are very similar to forward zones, except that named expects the target server to be authoritative-only, and therefore does not set the Recursion Desired (RD)bit on the queries it sends.
5. Mirror zones cannot be configured in named.conf unless within a view that has recursion enabled (per view or globally). This is because client queries requiring information from a mirror zone will fall back to using recursion during a period in which the mirror zone content is being refreshed and authenticated.