How can I improve the performance of cluster DNS?

Last verified 11 Nov 2026

Any region where your DOKS cluster is located has multiple DigitalOcean DNS server nodes. These DNS servers are rate limiting where DigitalOcean puts rate limits per server per source IP address.

DOKS uses CoreDNS to manage DNS requests within clusters. By default, DOKS clusters without the Cluster Proportional Autoscaler (CPA) plugin run two CoreDNS replicas to handle DNS requests.

DOKS enables CPA by default for new clusters running Kubernetes 1.36 or later. For clusters upgraded to Kubernetes 1.37 or later, DOKS enables CPA if CoreDNS still runs the default two replicas. When enabled, CPA scales CoreDNS replicas based on cluster size and overrides manual changes to the CoreDNS Deployment’s replica count. For details and tuning, see How to Configure CoreDNS Autoscaling.

Pods send DNS queries to the CoreDNS service, which routes them to CoreDNS endpoints. For public or external hostnames, CoreDNS forwards queries to DigitalOcean’s upstream DNS servers, distributing traffic across those servers. Pods using the host network also use DigitalOcean’s upstream DNS servers by default.

If your DOKS cluster generates a high volume of DNS queries, you may reach upstream DNS server quotas and experience dropped UDP packets.

Prometheus metrics can provide insights of your cluster’s DNS traffic. Depending on the DNS profile, you can use the following strategies to tune the DNS performance of your cluster.

Enable DNS Caching

NodeLocal DNSCache enables you to run a DNS caching agent on every cluster node to cache DNS results. When a pod makes a DNS request, it first reaches out to the DNS caching agent on the same node. Doing so avoids DNAT rules and connection tracking, which reduces the average DNS lookup time and improves the cluster DNS resolution performance. If the record is not present, then the caching agent queries the CoreDNS service. For more information, see Using NodeLocal DNSCache in Kubernetes Clusters in the Kubernetes documentation.

To enable NodeLocal DNSCache, create a nodelocaldns.yaml manifest and specify your values, as described in the Configuration section of the Kubernetes documentation.

Additionally, you need to customize the DNS settings of your workloads to use the <node-local-address> of the NodeLocal DNSCache. This is required because DOKS-specific iptables rules prevent the DNS cache instances from serving requests in the default NodeLocal DNSCache configuration.

Assuming a <node-local-address> of 169.254.0.5, a pod’s manifest looks similar to the following:

apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: my-org/my-image:v1.2.3
  dnsPolicy: None
  dnsConfig:
    nameservers:
      - 169.254.0.5
    searches:
      - kube-system.svc.cluster.local
      - svc.cluster.local
      - cluster.local
    options:
      name: ndots
      value: "5"

The nameservers value must be set to the <node-local-address> configured into NodeLocal DNSCache. Additionally, the dnsPolicy value must be set to none to prevent merging in the default CoreDNS name server from the Kubernetes environment. Consequently, other default resolv.conf settings, such as searches and options must also be explicitly defined as shown above.

For more information on how to specify the dnsConfig field of the pod, see Pod’s DNS Config in the Kubernetes documentation.

Use Non-Shared Machine Type for Cluster

Machines with shared CPU are prone to increased UDP latency. If your cluster has high DNS traffic, you can add a new node pool with a dedicated CPU machine type to the cluster. Then delete the node pool which has the Basic nodes. All machine types, except the Basic nodes, are dedicated CPU Droplets.

Alternatively, you can select a dedicated CPU machine type when creating a new cluster if you expect the cluster to have high DNS traffic.

Pin CoreDNS Pods to a Dedicated Node Pool

CoreDNS pods that share nodes with application workloads can experience DNS latency or dropped packets when those nodes run low on resources. Running CoreDNS on a dedicated node pool isolates it from that contention.

If your cluster doesn’t already have a pool for this purpose, add a node pool with a dedicated CPU machine type and note its name.

You can pin CoreDNS to the dedicated pool by adding a node affinity rule to the managed CoreDNS deployment. Avoid using a nodeSelector, which the DigitalOcean Kubernetes backend reverts during reconciliation or cluster upgrades. A node affinity rule persists across both.

Before you make any changes, back up the current CoreDNS deployment so you can restore it if needed:

kubectl get deployment coredns -n kube-system -o yaml > coredns-backup.yaml

Open the deployment for editing with kubectl edit deployment coredns -n kube-system, then add the following affinity configuration under spec.template.spec. If an affinity section already exists, add the nodeAffinity block to it without changing the existing settings. Replace <dedicated-nodepool-name> with the name of your dedicated node pool:

spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: doks.digitalocean.com/node-pool
                    operator: In
                    values:
                      - <dedicated-nodepool-name>

After you save and close the file, DOKS reschedules the CoreDNS pods onto the specified node pool. To confirm the move, run kubectl get pods -n kube-system -o wide | grep -i coredns and check that the node names in the output belong to your dedicated node pool.

Scale Out DNS Traffic

Scaling CoreDNS replicas can improve DNS performance. If your cluster has the CPA plugin enabled, CPA automatically scales CoreDNS based on cluster size. To adjust this behavior, customize the CPA scaling parameters.

To set the replica count manually, first disable the CPA plugin, and then scale the CoreDNS Deployment. For example, the following command increases the replica count to four:

kubectl scale deployment coredns -n kube-system --replicas=4

To verify the replica count, run the following command:

kubectl describe deployment coredns -n kube-system

Alternatively, after disabling CPA, you can configure automatic scaling by following the Enable DNS horizontal autoscaling instructions in the Kubernetes documentation.

Reduce DNS Traffic

If possible, reduce the DNS load your client applications send to the cluster.

How to Troubleshoot CoreDNS Issues in DOKS Clusters

Gather information to resolve CoreDNS-related DNS problems in DOKS clusters.

Why can't my VPC-native pods connect to my Droplets?

Droplets created before a VPC-native DOKS cluster in the same VPC network need routes added manually before the cluster’s pods can reach them.

How to Troubleshoot Load Balancer Health Check Issues

Health checks often fail due to firewalls or misconfigured backend server software.

We can't find any results for your search.

Try using different keywords or simplifying your search terms.