Stub zones don't work when primaries are configured for "minimal-responses yes;"
  • 05 Mar 2024
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Stub zones don't work when primaries are configured for "minimal-responses yes;"

  • Dark
    Light
  • PDF

Article Summary

When a stub zone is configured in named it seems to not work (and the resolver that has the stub zone responds SERVFAIL to client queries for names in that zone) if the target servers in the primaries server list are configured with minimal-responses yes; (or similar, if the target servers are not BIND).

The process for populating a stub zone from the primaries list is:

  1. Do SOA refresh query
  2. Check serial number
  3. If needed, refresh the zone.

So far, this is the same as when handling a secondary zone. But once named gets to the point of needing to do a zone transfer, if the zone type is stub rather than secondary, then instead of requesting AXFR or IXFR it does a regular query for the NS RRset.

Problems arise from this if the stub configuration is for a zone where the NS RRset consists of servers whose names are within the stub zone itself, but for which the query responses from the primaries that hold the NS RRset don't also deliver the address (A and/or AAAA) records.

No attempt is made by the stub zone to query the configured primaries for the missing address records, thus the stub zone is unusable and the outcome is SERVFAIL for resolution of any names in this zone.

If this was a secondary zone, we would get the address records (if appropriate, because they're in-zone) in the XFR. But this is not how stub zones work.

In essence a stub zone works like normal recursion, but with the configured primaries {}; list providing a shortcut straight to the servers that are authoriattive for this zone. Therefore, if those primaries don't provide address information for the NS, the stub zone is stuck.

stub zone possible development

If the resolver on which the stub zone is defined did make additional queries for the information it is missing (from an authoritative server that provides only minimal responses) then it would become unstuck. This capability may be added in a future release of BIND.

It used to be the case (in BIND) that the only two choices available for the minimal-responses statement were yes or no. But starting with BIND version 9.11 two new choices were added; no-auth and no-auth-recursive.

no-auth causes the server to omit records from the authority section except when they are required, but it may still add records to the additional section.

no-auth-recursive behaves the same way as no-auth if the query has the RD=1 flag set, but the same as no if this flag is not set. Since stub zones do not set the RD flag, configuring a BIND authoritative server with this choice (which is the default since 9.12) allows stub zones to work properly whilst still providing minimal responses to end user or forwarded queries, both of which set RD=1.