---
title: "Stub zone issues with \"minimal-responses yes;\""
slug: "stub-zones-dont-work-when-primaries-are-configured-for-minimal-responses-yes"
description: "When a stub zone is configured in named, it seems not to work if the zones in the primary server list are configured with \"minimal-responses yes;\"."
updated: 2024-03-05T13:45:14Z
published: 2024-03-05T13:45:14Z
canonical: "kb.isc.org/stub-zones-dont-work-when-primaries-are-configured-for-minimal-responses-yes"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

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

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.