Understand in-cluster DNS (CoreDNS)
CoreDNS provides in-cluster DNS for every pod in your cluster. It runs as a Deployment in kube-system behind the kube-dns service, resolving cluster-internal queries and forwarding external requests to upstream resolvers. This page explains how CoreDNS resolves service and pod domain names, how ndots lookups impact query performance, and how Syself Autopilot automatically manages and scales the deployment. For CoreDNS itself, see the CoreDNS docs.
In-cluster resolution and forwarding
CoreDNS answers two kinds of in-cluster names:
- Service names.
my-svc.my-namespace.svc.cluster.localresolves to the Service's cluster IP.cluster.localis the cluster's DNS suffix, set byserviceDomainwhen the cluster is created. The full naming scheme is in the Kubernetes DNS for Services and Pods reference. - Pod-backed names. A headless Service (
clusterIP: None) resolves to the individual pod IPs behind it, which is how StatefulSets get stable per-pod names.
Any query outside the cluster domain such as a public endpoint or internal network address is forwarded to the node's upstream resolver. You configure these resolvers using the dnsServers cluster variable, which populates the node's /etc/resolv.conf inherited by CoreDNS. To route private domain queries to internal name servers, see set up private and split DNS .
How ndots affects lookup performance
By default, Kubernetes configures /etc/resolv.conf inside pods with ndots: 5. If a queried domain contains fewer than five dots, the resolver appends each local search domain (<namespace>.svc.cluster.local, svc.cluster.local, cluster.local) before attempting the name as written. Looking up an external endpoint such as api.example.com (which has only two dots) therefore sends api.example.com.<namespace>.svc.cluster.local, api.example.com.svc.cluster.local, and api.example.com.cluster.local first—each returning NXDOMAIN—before the resolver finally queries api.example.com against upstream DNS.
To eliminate this query overhead on high-throughput workloads, configure the pod specification directly:
- Use fully qualified domain names (FQDN): Append a trailing dot (
api.example.com.) to external names to bypass the search list. - Lower
ndots: Set a customndotsvalue (for example,ndots: 2) in the pod'sdnsConfig.
How Syself scales CoreDNS
CoreDNS sits on the path of nearly every connection, so its replica count must grow with the cluster. Syself Autopilot runs the cluster-proportional-autoscaler against the CoreDNS Deployment and sizes it from the cluster's node and core counts:
| Setting | Value | Effect |
|---|---|---|
nodesPerReplica | 8 | one CoreDNS replica for every 8 nodes |
coresPerReplica | 256 | one replica for every 256 vCPUs across the cluster |
preventSinglePointFailure | true | at least 2 replicas once the cluster has more than one node |
The autoscaler takes the higher of the node-based and core-based counts, so CoreDNS scales up as you add nodes and back down as you remove them. You do not set a replica count, and you do not edit the Corefile. Both are reconciled by the platform, and a manual change is overwritten on the next reconciliation.
Note
Because CoreDNS is managed by Syself Autopilot, per-zone techniques that require a Corefile edit, such as a stub-domain forward block for one internal zone, are not available. To send private names to a private resolver, set the cluster's upstream with dnsServers, which routes every non-cluster name there. See Set up private and split DNS .