Container Service for Kubernetes:DNS FAQ

Why can't I exec into a CoreDNS Pod?

The CoreDNS container image is built on scratch, which has no shell. Running kubectl -n kube-system exec -it {coredns-pod-name} bash fails because no shell exists in the image.

To inspect the network environment of a CoreDNS Pod, use nsenter instead. See Check the network connectivity of a CoreDNS Pod for instructions. To view CoreDNS logs, enable the CoreDNS log analysis and monitoring feature. See Analyze and monitor CoreDNS logs.

Why is CoreDNS using a deprecated API?

During a cluster upgrade precheck, a client with the user agent coredns is accessing the deprecated discovery.k8s.io/v1beta1 API at /apis/discovery.k8s.io/v1beta1.

This happens for one of two reasons:

• Outdated CoreDNS version: The installed version does not support discovery.k8s.io/v1, so it falls back to v1beta1.

• Stale API selection: CoreDNS was started on an older Kubernetes version (for example, v1.20) and locked in v1beta1 at startup. After a cluster upgrade deprecated that API, CoreDNS kept using it.

In both cases, upgrade CoreDNS first. If an upgrade is not available, restart it to force a fresh API selection.

To upgrade or restart CoreDNS:

1. Log on to the ACK console and click Clusters in the left navigation pane.

2. Click your cluster name. In the left navigation pane, click Add-ons.

3. On the Add-ons page, upgrade the CoreDNS component. If the page shows that an upgrade is not possible, proceed to step 4. For more information, see Manage components.

4. Restart CoreDNS:

   kubectl -n kube-system rollout restart deployment coredns

   Important

   DNS resolution errors may occasionally occur during the restart. See Mitigate intermittent DNS timeouts caused by IPVS defects to reduce the impact.

5. Verify that the CoreDNS Pods are running:

   kubectl -n kube-system get pod -l k8s-app=kube-dns

   The expected output shows newly recreated Pods in Running state:

   NAME                       READY   STATUS    RESTARTS   AGE
   coredns-xxxxxxxxxx-xxxxx   1/1     Running   0          30s
   coredns-xxxxxxxxxx-yyyyy   1/1     Running   0          28s

   Once both Pods are in Running state, the deprecated API call records on the precheck page can be safely ignored and you can proceed with the cluster upgrade.

CoreDNS log error: dns: buffer size too small

CoreDNS sets its default UDP buffer size (bufsize) to 1232 bytes. When a DNS response exceeds this limit, resolution fails and the error dns: buffer size too small appears in the logs. This typically affects DNS queries that return large responses. For background, see this GitHub issue.

Upgrade CoreDNS to v1.7.1 or later, which resolves this automatically. For versions earlier than v1.7.1, manually set bufsize in the CoreDNS ConfigMap:

kubectl edit cm -n kube-system coredns

Add bufsize with a value in the range \[512, 4096\] (inclusive):

. {
    bufsize 1220
    log
}

For more information, see the CoreDNS bufsize plugin documentation.

Why do requests return NXDOMAIN and NOERROR inconsistently after a Service is created?

CoreDNS runs as multiple Pod replicas. Right after a new Service is created, one Pod may not have retrieved the latest Service information from the API server yet, while another Pod already has. Requests routed to the out-of-sync Pod return NXDOMAIN; requests routed to the updated Pod return NOERROR. The inconsistency resolves on its own once all CoreDNS Pods sync with the API server. No manual action is needed.

DNS resolution on Windows nodes

Pods on Windows nodes have several DNS behaviors that differ from Linux:

• ClusterFirstWithHostNet is not supported. Windows does not support this DNS policy for Pods.

• All names containing a period (.) are treated as fully qualified domain names (FQDNs). Windows does not append DNS search suffixes for names with a dot, unlike Linux, which walks a search suffix list.

• Only one DNS suffix is used per Pod. The suffix is derived from the Pod's namespace—for example, a Pod in the default namespace gets the suffix default.svc.cluster.local. This means kubernetes.default.svc.cluster.local and kubernetes resolve correctly, but partially qualified names such as kubernetes.default or kubernetes.default.svc do not.

• Use Resolve-DnsName for DNS queries. Windows supports multiple DNS resolvers with minor behavioral differences. The Resolve-DnsName PowerShell cmdlet gives the most consistent results.

For more information, see DNS for Services and Pods.