selective forwarding resolver that isn't being selective

[Mike]

I set up BIND9 9.20 as a container in a Kubernetes cluster so that it could
provide DNS services for all of my internal systems, via an "internal" view.
Currently it also provides authoritative responses for some secondary servers
in a hidden master configuration, but that's done via an "external" view.

The cluster is authoritative for its pods and services, so I forward those
zones to the cluster's CoreDNS.  The CoreDNS inherits the usual
/etc/resolv.conf of the internal systems, so it forwards queries for things
it doesn't know up to the BIND container.  It's a bit cyclic, but the
queries *should* get answered in the appropriate servers.

I was *expecting* that "internal" view of the BIND container would
recursively resolve everything else: all the non-k8s and non-local zones.  A
query for google.com should go out to the root servers, the com. server, etc.
The view has "recursion yes;" and "match-clients" for the internal IPs.
Options has "allow-recursion" for the internal IPs.  I even set
"forwarders {};" for the view to see if that would help.

But a tcpdump shows that the BIND container will even forward to the CoreDNS
for queries like "./NS".  And then CoreDNS forwards back to BIND, and the
query eventually fails.

I don't even know where BIND is getting the IP address of the CoreDNS
container from!  I even overrode the /etc/resolv.conf in its container with
a dnsPolicy/dnsConfig that only references the upstream ISP's servers.

This wasn't a problem until I recently noticed that NetworkPolicy was
prohibiting CoreDNS from querying the BIND container and corrected the
policy.

I don't see anything useful in the debug-level logging with "rndc trace 7",
no explanation about its choices.

Ideas?