Container Compute Service:DNS resolution policies and caching policies

DNS resolution pipelines

The following diagrams show the DNS resolution pipeline for two scenarios.

Non-containerized applications on Elastic Compute Service (ECS) instances

For example, an application named App runs on an ECS instance, as shown in the following figure.

Containerized applications in pods with the ClusterFirst DNS policy

For example, an application named App runs in a pod in a Kubernetes cluster, as shown in the following figure.

Resolution policies

Client side

DNS queries from pods are handled through the interfaces provided by glibc. The /etc/resolv.conf file controls how glibc performs DNS resolution. The following table lists the configurable parameters and their default values across environments.

The following table describes what each DNS policy means for query routing.

① The attempts parameter applies only when the server returns SERVFAIL, NOTIMP, or REFUSED, or when NOERROR is returned with no resolution results. For details, see Introduction to the attempts parameter.

② VPC DNS servers are the default nameservers for ECS instances in the virtual private cloud (VPC). Their IP addresses are 100.100.2.136 and 100.100.2.138. They resolve authoritative domain names and domain names added to Alibaba Cloud DNS PrivateZone.

③ The CoreDNS cluster IP is the IP address of the kube-dns Service in the kube-system namespace. The kube-dns Service forwards DNS queries to CoreDNS for internal domain names, authoritative domain names, and domain names added to Alibaba Cloud DNS PrivateZone.

Non-standard environments

The client-side DNS configuration described above applies to environments using glibc. The following environments behave differently.

Alpine Linux (musl libc)

Alpine Linux replaces glibc with musl libc, which introduces several DNS resolution differences:

• single-request and single-request-reopen are not supported in /etc/resolv.conf.

• Alpine 3.3 and earlier do not support the search parameter for search domains. This causes service discovery to fail.

• musl libc sends queries to all nameservers in /etc/resolv.conf in parallel, which prevents NodeLocal DNSCache from optimizing DNS resolution.

• musl libc sends A and AAAA queries in parallel over the same socket. On older kernel versions, this causes packet loss on the conntrack port.

For more information, see musl libc functional differences from glibc.

Golang and Node.js

Applications built with Golang or Node.js may use a built-in DNS resolver instead of glibc. This can produce significantly different DNS resolution behavior. Check your application's DNS resolution implementation if you observe unexpected behavior.

Internal DNS servers in the cluster

By default, CoreDNS inherits /etc/resolv.conf from the ECS instance that hosts it. CoreDNS then uses the built-in forward plugin to forward DNS queries upstream.

The following table lists the forward plugin parameters and their default values. For the full reference, see forward.

Caching policies

Client side

The DNS caching policy at the client side depends on the container and application configuration. Configure client-side caching based on your requirements.

Internal DNS servers in the cluster

CoreDNS uses the cache plugin to cache DNS resolution results. The following table lists the cache plugin parameters and their default values in ACS.

Optimize DNS resolution

Modify the pod YAML file or the CoreDNS ConfigMap to tune DNS resolution behavior.

Use VPC DNS servers directly

Set dnsPolicy: Default to bypass CoreDNS and resolve domain names directly through VPC DNS servers. The pod inherits the DNS settings of the ECS instance that hosts it.

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default

# The /etc/resolv.conf file in the pod.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

Improve fault tolerance for Default pods

When dnsPolicy: Default is set, the pod's /etc/resolv.conf omits the rotate, single-request-reopen, timeout:2, and attempts:3 options that ECS instances include by default. Without these options, DNS resolution is more likely to fail during network jitter.

Add these options using dnsConfig to match the ECS instance behavior:

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # Set the dnsPolicy parameter to Default.
  dnsPolicy: Default
  # Add the following options.
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After adding the options, redeploy the pod to apply the changes.
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3