Opening this as a public issue, as there are already public discussions and integration into penetration testing tooling.

CoreDNS's wildcard feature (specifically wildcards in Kubernetes) present an information disclosure.

CoreDNS has several plugins that support wildcard lookups, including the file, etcd, and kubernetes plugins. In environments such as Kubernetes where Service Discovery is desired, full enumeration of Services, Namespaces, and Endpoint IPs is possible even when Kubernetes API permissions or authentication is denied.

Administrators can disable the mounting of Kubernetes Service Account tokens and deny the pod any identity in the Kubernetes API. They can disable Docker links compatibility to limit same-namespace service discovery in a pod. They can also use spec.dnspolicy or spec.dnsConfig to use alternate nameservers instead of CoreDNS, but that prevents any in-cluster service discovery.

For an administrator who considers namespaces, service names, or pod IPs (or the number of pod IPs behind a service) to be confidential and still wants service discovery, they have no way to disable wildcard service listing in their cluster.

This is particularly concerning if anyone were to run untrusted code in a cluster where that code executes lookups against CoreDNS. Barriers such as node-affinity/taints and tolerations, or encapsulation mechanisms like Google's gVisor or Kata containers are of no benefit if DNS requests are sent to CoreDNS.

If this were considered a vulnerability, my initial CVSS estimate would rate it as a Medium 4.3

What would you like to be added:

I propose a new configuration for the Kubernetes plugin to disable wildcard lookups. For backward compatibility, wildcards may need to be on by default, but a deprecation path where wildcards are disabled by default would be greatly beneficial.

CC: @JayBeale @raesene