Tigera Logo

Guides: Kubernetes DNS Service

Kubernetes DNS Service: Practical Guide to DNS in Kubernetes

How Does DNS Work in Kubernetes?

Kubernetes automatically manages DNS records for all Services to enable built-in service discovery. Instead of tracking changing IP addresses, Pods within the cluster can communicate with any Service using a stable, human-readable domain name. CoreDNS, the default cluster DNS server, watches the Kubernetes API and keeps these records in sync as Services and Pods change.

The Domain Name System (DNS) is used in Kubernetes to enable name resolution within a cluster. It translates service names into IP addresses, allowing applications to communicate. In Kubernetes, DNS is integrated to automatically provide DNS names for various cluster services, allowing them to be accessed via user-friendly names rather than complex IP addresses.

DNS record types by Service type:

  • Standard Services: Map to a single A (IPv4) or AAAA (IPv6) record pointing to the Service’s stable ClusterIP.
  • Headless Services: Defined with clusterIP: None, they resolve directly to A/AAAA records for the IPs of all ready backend Pods.
  • ExternalName Services: Map the internal name to an external domain using a CNAME record, with no ClusterIP involved.
  • SRV records: Created to discover the named TCP or UDP ports defined within a Service.

How Kubernetes DNS works behind the scenes:

  • Default server: CoreDNS is the default cluster DNS provider, running as Pods exposed through a Service named kube-dns in the kube-system namespace.
  • API tracking: CoreDNS continuously monitors the Kubernetes API for new, modified, or deleted Services and Endpoints.
  • Dynamic updates: It updates its records so each DNS name maps to the correct ClusterIP or Pod IPs in real time.

DNS works hand-in-hand with cluster-level access controls — for restricting which pods can talk to which services, see our guide to Kubernetes network policy.

Beyond DNS, securing the underlying workloads is essential — see our guide to container security best practices.

This is part of a series of articles about Kubernetes networking.

In this article:

Importance of DNS for Communication Within a Kubernetes Cluster

DNS is vital for managing internal cluster communications in Kubernetes. It provides a systematic way to reference and locate services and pods, facilitating inter-service communications. Without DNS, developers would need to manually track IP addresses, an infeasible task when scaling applications across numerous nodes and dynamic environments.

With DNS, services can be accessed through identifiable names, reducing complexity for developers. This ability to quickly resolve names to IPs is crucial when handling service discovery within the Kubernetes ecosystem. It ensures consistent communication, which is fundamental for deploying reliable and scalable applications across the distributed framework of Kubernetes.

Understanding Kubernetes DNS Resolution

Default Domain Name: cluster.local

In a Kubernetes cluster, the default domain name is cluster.local. This domain is automatically appended to any service or pod name that doesn’t include a fully qualified domain name (FQDN). The use of a default domain simplifies internal DNS resolution by creating a consistent naming structure across the cluster. For instance, if you reference a service name without specifying a domain, Kubernetes resolves it within the cluster.local domain by default.

This default domain configuration ensures that services and pods can communicate without needing to reference their complete DNS names, streamlining service discovery within the cluster. Additionally, this approach prevents conflicts with external DNS names, as the cluster.local domain is reserved solely for internal use within the Kubernetes cluster.

DNS Name for Services

Every Service in a Kubernetes cluster is automatically assigned a Fully Qualified Domain Name (FQDN), so other workloads can find it through built-in service discovery. In Kubernetes, services are assigned a DNS name that allows them to be easily accessible within the cluster. The DNS name for a service follows the format <service-name>.<namespace>.svc.cluster.local.

Here’s how each part of this DNS name works:

  • <service-name>: This is the name of the service as defined in the Kubernetes manifest file.
  • <namespace>: Kubernetes namespaces are used to organize resources within a cluster. The namespace in the DNS name ensures that services with the same name in different namespaces can coexist without conflict.
  • svc: This is a standard suffix that indicates the resource is a service.
  • cluster.local: This is the default domain for the Kubernetes cluster.

For example, if you have a service named my-service in the default namespace, its full DNS name would be my-service.default.svc.cluster.local.

DNS Name for Pods

Pods in Kubernetes can also be accessed via DNS, though this is typically less common than accessing services. Each pod within a stateful set or with a defined hostname and subdomain can have a DNS name, which follows the pattern <pod-name>.<headless-service-name>.<namespace>.svc.cluster.local.

Here’s how it breaks down:

  • <pod-name>: This is typically the name of the pod, which might be automatically generated if not explicitly set by the user.
  • <headless-service-name>: A headless service, which is a service with no cluster IP (ClusterIP: None), is required to resolve individual pod DNS names. This service is responsible for enabling DNS-based service discovery to individual pods.
  • <namespace>: Similar to service DNS names, this ensures the DNS names are unique across different namespaces.
  • svc: This indicates that the resource is part of a service.
  • cluster.local: This signifies the DNS name is internal to the Kubernetes cluster.

For instance, if you have a pod named web-0 in a StatefulSet called web within the prod namespace, its DNS name might be web-0.web.prod.svc.cluster.local.

Pods and Services Interaction Using DNS Names

When a pod needs to interact with a service, it uses the service’s DNS name. Kubernetes resolves this DNS name to the service’s IP address, allowing the pod to connect to the service without needing to know the underlying IP address, which might change due to scaling or rescheduling of pods. This abstraction simplifies the management of connections between services and improves the resilience of the application.

For example, if a pod in the default namespace needs to connect to a service named database, it would typically use the DNS name database.default.svc.cluster.local. Kubernetes handles the name resolution, directing traffic to the appropriate service, which in turn forwards it to one of its associated pods.

In more complex scenarios, such as those involving StatefulSets or headless services, pods can directly interact with other pods using their individual DNS names. This is particularly useful when each pod requires a stable network identity, such as in a distributed database cluster where each node must be uniquely addressable.

Related content: Read our guide to Kubernetes debugging

Shortened Names and Search Paths

The Kubernetes Kubelet automatically configures the /etc/resolv.conf file inside every Pod. This lets you omit parts of a Service’s domain name depending on where the client Pod runs:
  • Same namespace: If the client Pod and the Service are both in the prod namespace, you can use just the service name, such as frontend.
  • Different namespace: If the client Pod is in the dev namespace and wants to connect to frontend in prod, you can use frontend.prod.
Kubernetes appends the remaining search domains (such as svc.cluster.local) automatically, so short names resolve to the correct Service without writing out the full FQDN.

DNS Record Types by Service Type

The type of DNS record Kubernetes generates depends entirely on how the Service is configured:
  • Standard Services: Map to a single A (IPv4) or AAAA (IPv6) record pointing to the Service’s stable ClusterIP.
  • Headless Services: Services defined with clusterIP: None bypass the ClusterIP entirely. The DNS query resolves directly to a set of A/AAAA records containing the individual IP addresses of all ready backend Pods.
  • ExternalName Services: Do not use IP addresses. Instead, they map the internal name directly to an external domain using a DNS CNAME record.
  • SRV records: Kubernetes also creates SRV records to discover the named TCP or UDP ports configured within your Service definitions.

What Is CoreDNS in Kubernetes?

CoreDNS is the default DNS server in Kubernetes, playing a crucial role in name resolution within the cluster. It provides a flexible and efficient DNS service tailored to Kubernetes environments, replacing the older kube-DNS service.

Key features of CoreDNS:

  1. Modular architecture: CoreDNS is built with a modular design, allowing it to support a variety of plugins that can be enabled or disabled based on the needs of the cluster. This modularity makes CoreDNS customizable, enabling it to handle not just DNS resolution, but also other tasks such as load balancing, service discovery, and even health checks.
  2. Efficient resource usage: CoreDNS is lightweight and optimized for performance, ensuring minimal resource consumption while handling DNS requests. This efficiency is particularly important in Kubernetes, where the DNS service must scale to meet the demands of large, dynamic clusters.
  3. Service discovery: CoreDNS facilitates service discovery by automatically updating DNS records as services and pods are added, removed, or modified within the cluster. This dynamic updating ensures that applications can consistently locate the services they depend on, even in a rapidly changing environment.
  4. Advanced configuration: With CoreDNS, administrators can fine-tune DNS behavior using a simple yet powerful configuration language. This allows for precise control over how DNS queries are handled, enabling optimizations such as caching, forwarding requests to upstream servers, or splitting DNS traffic based on specific domains.
  5. Enhanced security: CoreDNS supports DNSSEC (DNS Security Extensions) and other security features, helping to protect the cluster’s DNS infrastructure from various attacks, such as cache poisoning and spoofing.

CoreDNS is deployed as a set of pods within the Kubernetes cluster, usually running in the kube-system namespace. These pods are managed by a Deployment or DaemonSet, ensuring high availability and scalability. By default, CoreDNS listens for DNS queries on the standard DNS port (53) and handles all internal name resolutions within the cluster. Inside the cluster, CoreDNS is exposed through a Service named kube-dns in the kube-system namespace. It continuously watches the Kubernetes API for new, modified, or deleted Services and Endpoints, and updates its records so that each DNS name maps to the correct ClusterIP or Pod IPs in real time.

Below is a simple CoreDNS configuration file (Corefile) example that demonstrates a basic setup for a Kubernetes cluster:

.:53 {
errors
health {
    lameduck 5s
}
kubernetes cluster.local in-addr.arpa ip6.arpa {
    pods insecure
    fallthrough in-addr.arpa ip6.arpa
    ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}

Explanation of the configuration:

  • .:53: CoreDNS listens on port 53 for DNS queries across all interfaces (.).
  • errors: Logs any errors that occur when processing DNS queries.
  • health: Enables a health check endpoint, with a lameduck period of 5 seconds before CoreDNS shuts down.
  • kubernetes cluster.local in-addr.arpa ip6.arpa: This plugin handles DNS queries for Kubernetes services and pods within the cluster.local domain. It also supports reverse DNS lookups (in-addr.arpa for IPv4 and ip6.arpa for IPv6).
    • pods insecure: Allows DNS lookups for pod IPs without requiring DNSSEC.
    • fallthrough in-addr.arpa ip6.arpa: If a query doesn’t match Kubernetes records, it falls through to other plugins for resolution.
    • ttl 30: Sets the Time To Live (TTL) for responses to 30 seconds.
  • prometheus :9153: Exposes CoreDNS metrics on port 9153 for Prometheus monitoring.
  • forward . /etc/resolv.conf: Forwards queries that cannot be resolved internally to the upstream DNS servers specified in /etc/resolv.conf.
  • cache 30: Caches DNS responses for 30 seconds to improve performance.
  • loop: Detects and prevents DNS query loops.
  • reload: Automatically reloads the configuration when changes are detected.
  • loadbalance: Distributes DNS queries across multiple endpoints for better load distribution.

Kubernetes Security and Observability with Calico

Tigera’s commercial Calico solutions provide comprehensive security and observability for Kubernetes-based environments, covering multi-cluster, multi-cloud, and hybrid-cloud deployments. Additionally, Calico can be applied to baremetal and non-cluster hosts, offering a unified approach to securing and monitoring diverse infrastructure. Both Calico Enterprise and Calico Cloud provide the following features for security and observability:

Security

  • Zero trust for workloads – Prevent lateral movement of threats and maintain compliance by applying fine-grained security policies to restrict communication between workloads and third-party applications, the internet, and other workloads.
  • Compliance reporting and alerts – Continuously monitor and enforce compliance controls, easily create custom reports for audit.
  • Intrusion detection & prevention (IDS/IPS) – Detect and mitigate Advanced Persistent Threats (APTs) using machine learning and a rule-based engine that enables active monitoring.
  • Microsegmentation across Host/VMs/Containers – Deploy a scalable, unified microsegmentation model for hosts, VMs, containers, pods, and services that works across all your environments.
  • Data-in-transit encryption – Protect sensitive data and meet compliance requirements with high-performance encryption for data-in-transit.
  • Application-layer security – Calico uses eBPF to monitor application traffic in real time, providing robust security and visibility into network communications. By integrating with DNS infrastructure, Calico also gains insights into domain name resolution processes, detecting anomalies that may indicate malicious activity.

Observability

  • Dynamic Service and Threat Graph – Observe upstream and downstream dependencies for microservices, and service-to-service interactions within a Kubernetes cluster, with a dynamic live view that helps identify security gaps and troubleshoot connectivity issues faster.
  • Application-Layer Observability – Gain visibility into service-to-service communication within your Kubernetes environment, without the operational complexity and performance overhead of service mesh.
  • Dynamic Packet Capture – Perform packet capture for a specific pod or collection of pods with this self-service, on-demand tool. The tool integrates with Kubernetes RBAC to limit and secure users’ access to the endpoints and namespaces assigned to them.
  • DNS Dashboard – Quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues in Kubernetes.
  • Flow visualizer – Get a 360-degree view of a namespace or workload, including analytics around how security policies are being evaluated in real time and a volumetric representation of flows.

Next steps:

X