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?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
