Tigera Logo

Guides: Kubernetes DNS Service

Kubernetes DNS Service: Practical Guide to DNS in Kubernetes

How Does DNS Work in Kubernetes?

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 in Kubernetes simplifies networking by automating the assignment of service names to pods and services. This eliminates the need for manual configuration, ensuring easier interactions. DNS resolution is integrated with Kubernetes deployments to dynamically update and resolve service names in real time, keeping applications connected as the cluster changes.

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

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

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.

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