All Products
Search
Document Center

Container Service for Kubernetes:DNS overview

Last Updated:Mar 27, 2026

In a Kubernetes cluster, pods use domain names to access Services or external services. These domain names must be resolved to IP addresses to allow access. DNS handles this by maintaining a mapping between domain names and IP addresses. This topic describes the basics of DNS, the DNS components in ACK, and DNS configuration.

How domain name resolution works

Although devices on the internet communicate by using IP addresses, domain names are easier to remember because they are more semantic. As a result, clients almost always use domain names to initiate requests. The following figure shows the process when a client sends a request to example.com.

image
  1. The server registers its IP address and domain name with a DNS server, which stores the corresponding record.

  2. The client asks the DNS server for the IP address that corresponds to example.com.

  3. The DNS server looks up the record and returns the IP address to the client.

  4. The client uses the IP address to access the target server.

Domain name types in a cluster

  • Internal domain name: The domain name of a Service, which is valid only within the cluster. We recommend that you use the fully qualified domain name (FQDN) format, <service-name>.<namespace>.svc.<cluster-domain>, to access the Service. Using a short domain name (<service-name>) causes excessive invalid DNS queries and increases resolution time.

    The cluster-domain is a custom setting configured during cluster creation, which defaults to cluster.local.
  • External domain name: Includes VPC-internal domain names and public domain names. To resolve these domain names, CoreDNS must get the result from an upstream DNS server. By default, the upstream DNS server is the PrivateZone service, with the IP addresses 100.100.2.136 and 100.100.2.138.

    Important

    PrivateZone does not provide a Service Level Agreement (SLA) for the recursive resolution of public domain names. For the limitations of recursive resolution, see Manage recursive queries.

DNS components in a cluster

In an ACK managed cluster, two components handle DNS: CoreDNS and NodeLocal DNSCache.

CoreDNS

CoreDNS is available in two modes: managed and unmanaged.

Comparison item

Managed CoreDNS

Unmanaged CoreDNS

Applicable clusters

  • ACK managed cluster

  • ACK dedicated cluster

  • ACK Serverless cluster

Deployment mode

Deployed on the control plane and fully managed by ACK.

On the Component Management page in the console, hosted component cards display Hosted.

Deployed as a workload (Deployment) in the cluster. By default, it is installed in the kube-system namespace and consumes resources on worker nodes.

O&M responsibility

Alibaba Cloud is responsible for component O&M.

Follows a shared responsibility model:

  • Alibaba Cloud provides component software versions, technical support, and configurable parameters to assist with O&M.

  • You are responsible for ensuring the cluster has sufficient resources to deploy CoreDNS, enabling logging and monitoring alerts, and managing the component's resource specification, upgrades, and scaling. For configuration details, see Recommendations for deploying stable and high-performance Unmanaged CoreDNS.

Features

  • Supports autoscaling by default. The scaling process takes about 5 to 10 minutes.

  • Supports custom parameter configuration for common use cases through CRDs.

  • Supports custom resource specifications for the component.

  • Autoscaling is not configured by default but can be manually configured.

  • You can customize the configuration by modifying the ConfigMap named coredns in the kube-system namespace.

Logging

Logging is enabled by default.

Supported, but you must manually enable CoreDNS logging.

Monitoring and alerting

Supports Prometheus monitoring. You must set up and configure monitoring for the cluster.

Performance

For more information, see Managed CoreDNS performance.

Depends on the component configuration.

Unmanaged CoreDNS

CoreDNS is a component in a Kubernetes cluster that handles DNS resolution. It can resolve both internal service domain names and external domain names. The CoreDNS project is hosted by the Cloud Native Computing Foundation (CNCF). For more information, see CoreDNS: DNS and Service Discovery.

Following the open-source Kubernetes standard, ACK clusters install CoreDNS as the default DNS server. CoreDNS is deployed as a Deployment in the kube-system namespace. kube-dns is the ClusterIP-type Service for CoreDNS. For information about how to configure CoreDNS, see Configure Unmanaged CoreDNS.

Use kubectl to view CoreDNS resources

  1. View the Deployment

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

    Expected output:

    NAME      READY   UP-TO-DATE   AVAILABLE   AGE
    coredns   2/2     2            2           1h
  2. View the Service

    kubectl get service -n kube-system kube-dns

    Expected output:

    NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
    kube-dns   ClusterIP   172.**.**.**   <none>        53/UDP,53/TCP,9153/TCP   1h

In the following example, a Pod in the default namespace attempts to access database-svc and goes through the following process:

image
  1. The pod checks the /etc/resolv.conf configuration file and determines that the IP address of the DNS server is 172.0.XX.XX. This is the ClusterIP of kube-dns. An example of the configuration file is as follows.

    nameserver 172.0.XX.XX                                              # Defines the IP address of the DNS server.
    search default.svc.cluster.local svc.cluster.local cluster.local    # Sets the search suffix rules for domain names. The more search paths are configured, the more lookup attempts are made.
    options ndots:5                                                     # Defines options for the domain name resolution configuration file. Multiple key-value pairs are supported.
  2. A pod sends a DNS query to kube-dns, using the values in the search field as suffixes to sequentially resolve the following names:

    1. database-svc.default.svc.cluster.local (A Service in the same namespace as the pod)

    2. database-svc.svc.cluster.local (A Service in another namespace)

    3. database-svc.cluster.local (cluster-scoped domain name)

    4. database-svc (external domain name)

  3. The CoreDNS pod returns the result, which is the IP address 172.4.XX.XX.

  4. The pod uses this IP to access the target service database-svc.

  5. If the request is for an external domain name, such as a VPC-internal domain name or a public domain name, the CoreDNS pod forwards the query to the upstream DNS server.

    Important

    Do not modify the DNS server configuration on the node because CoreDNS inherits the upstream DNS server address from the node on which it runs.

    CoreDNS configuration is stored in the coredns ConfigMap in the kube-system namespace. In the default configuration, the forward plugin points to /etc/resolv.conf. This means that for upstream DNS queries, CoreDNS uses the DNS server addresses from its container's /etc/resolv.conf file. The /etc/resolv.conf file in the CoreDNS container is, by default, the same as the /etc/resolv.conf file on its host node, which uses the default DNS server addresses 100.100.2.136 and 100.100.2.138. If you modify the DNS server configuration on the node, CoreDNS will use incorrect upstream DNS addresses, leading to resolution failures or unexpected results.

        .:53 {
            ...
            forward . /etc/resolv.conf {
              prefer_udp
            }
            ...
        }

Managed CoreDNS

Managed CoreDNS works on the same principle as Unmanaged CoreDNS but is fully managed by ACK. It does not consume cluster resources and requires no O&M from you. It also autoscales based on the load. For more information, see Managed CoreDNS performance.

Managed CoreDNS is supported in ACK managed clusters with auto mode enabled. To use an ACK managed cluster with auto mode enabled, see Create an ACK managed cluster with auto mode enabled.

NodeLocal DNSCache

NodeLocal DNSCache configures a DNS cache on each worker node to reduce the load on CoreDNS and improve cluster DNS stability and availability. We recommend that you install this component in scenarios with high DNS load or strict requirements for DNS response speed and stability. To install and use the component, see Use the NodeLocal DNSCache component.

In the following example, after NodeLocal DNSCache is installed and the node-local-dns-injection: "enabled" label is added to the default namespace, a pod in the default namespace attempts to access database-svc and goes through the following process:

image
  1. The pod first checks the DNS cache on its node.

  2. The process proceeds in one of two ways, depending on whether a cache hit occurs:

    1. A cache hit occurs if the node's DNS cache contains a record for database-svc. The cache returns the result, and the pod uses this result to access the service.

    2. If a cache miss occurs, meaning the node's DNS cache does not have a record for database-svc, the result is retrieved from CoreDNS. The result from CoreDNS is then cached in the node's DNS cache for future use.

Cluster DNS configuration

DNS in a cluster can be configured at three different levels, each with a different scope.

Cluster configuration

ClusterDomain is a kubelet configuration on each node. This configuration must be consistent across all kubelets in the cluster. Otherwise, network errors will occur.

  • ClusterDomain

    ClusterDomain is the local top-level domain of a cluster and the default suffix for the full domain names of all Services within the cluster. The default value is cluster.local. The ClusterDomain configuration is typically used to distinguish between in-cluster and out-of-cluster networks. When you create a cluster, you can customize the ClusterDomain. Ensure that the custom domain name does not conflict with commonly used external domain names.

    image.png

Node configuration

  • resolveConf

    resolveConf specifies the path to the DNS configuration file on the node. When a pod's dnsPolicy is Default, the kubelet copies the file specified by resolveConf (which defaults to /etc/resolv.conf) to the pod's /etc/resolv.conf.

Pod configuration

  • Each pod has two configurations to customize its DNS policy: dnsPolicy defines the DNS resolution policy, and dnsConfig is used to specify custom DNS servers and search domains. For more information about how to use dnsPolicy and dnsConfig together in different scenarios, see DNS Policy Configuration and Domain Name Resolution.