Why does my authoritative server make recursive queries?
  • 01 Aug 2023
  • 6 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Why does my authoritative server make recursive queries?

  • Dark
    Light
  • PDF

Article summary

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)
How to prevent these queries from happening

You can explicitly disable the default notifies (which will be sent to all other servers whose NS RRs are in a zone) by specifying notify no; (no notifies will be sent at all) or notify explicit with a list of IP addresses to which you want to send notifies.

  1. 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.
How to disable Trust Anchor Maintenance

If you are not running a resolver, then you do not need DNSSEC-validation. The easiest way to be certain that you're not doing DNSSEC-validation is to disable it explicitly:
dnssec-validation no;
This will prevent named from automatically loading the built-in trust anchors. For more information about default trust anchors, see the BIND Administrator Reference Manual and its documentation for the option dnssec-validation.

In addition, you should ensure that you have not explicitly added any trust anchors to your configuration of type initial-key since these will still be maintained, even if your configuration doesn't need to use them.

  1. 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.
How to disable Trust Anchor Telemetry

If you have no active trust anchors in your configuration (manually or automatically loaded), then there will be no queries sent by named for the purposes of providing telemetry to zone operators, but it is also possible to disable this feature globally or per-view in named.conf by adding this option:
trust-anchor-telemetry no;

  1. 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).
How do I know if I have any active Negative Trust Anchors?

It is unlikely that anyone running an authoritative-only server would use the rndc command to add Negative Trust Anchors since these would only be used by a DNSSEC-validating resolver. However, adding them to a running authoritative-only server is not prevented. Therefore if you want to confirm that you have no NTAs, the rndc nta command provides a dump option to list any that are active:
rndc nta dump

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.