Bug #45734 for bind9-public: Stub zones don't work when masters are configured for "minimal-responses yes;"

When a stub zone is configured in named, it seems not to 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 masters 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 masters list seems to be: - do SOA refresh query - check serial number - if needed, 'refresh' the zone. So far, this is the same as when handling a slave zone, but once named gets to the point of needing to do a zone transfer, when the zone type is 'stub' rather than 'slave', 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 masters {}; with the NS RRset don't also deliver the address (A and AAAA) records. No attempt is made to query the configured masters for the missing address records, thus the stub zone is unusable, and the outcome is server failure on any resolution of names in this zone. If this was a slave zone, we would get the address records (if appropriate, because they're in-zone) in the AXFR; I don't therefore see any reason why named couldn't make direct queries to the listed masters for the zone for the address records, if they didn't arrive with the NS RRset. --- Many authoritative servers have "minimal-responses yes;" nowadays, and it many not be possible to have them configured otherwise for stub zones to work with them --- Workarounds in this case are: a) Use a full slave zone instead of a stub b) Use static-stub