8.12 DNS in Kubernetes

Abstract

Kubernetes DNS allows Pods to discover Services and, when enabled, Pods using DNS names instead of hardcoding IP addresses.

Kubernetes deploys an internal DNS service, commonly CoreDNS, so workloads can resolve names like web-service, web-service.apps, or web-service.apps.svc.cluster.local.

In production, DNS is critical for service discovery, application communication, and stable workload connectivity.

Why DNS is Needed in Kubernetes

Pods and Services get IP addresses, but relying on IPs is not practical.

Pod IPs can change when:

Pods restart
Pods are recreated
Pods move to another node
Deployments scale up or down

Services provide stable virtual IPs, and DNS provides stable names for those Services.

Note

Applications should connect using Service DNS names, not Pod IPs.

Kubernetes DNS Scope

Kubernetes DNS mainly resolves names for:

Services
Pods, when Pod DNS records are enabled
internal cluster domains

It does not primarily manage node hostnames.

Tip

Node names such as node1.kubecluster.org are usually handled by your infrastructure or organization DNS, not Kubernetes DNS.

DNS Server in Kubernetes

Kubernetes deploys an internal DNS server.

In modern clusters, this is usually:

CoreDNS

CoreDNS runs inside the cluster and watches the Kubernetes API for Services and Endpoints.

Success

When a Service is created, Kubernetes DNS automatically creates DNS records for it.

Example Cluster

Example nodes:

Node	Hostname	IP Address
Node 1	`node1.kubecluster.org`	`192.168.1.11`
Node 2	`node2.kubecluster.org`	`192.168.1.12`
Node 3	`node3.kubecluster.org`	`192.168.1.13`

Example workloads:

Object	Namespace	IP Address
`test` Pod	`default`	`10.244.1.5`
`web` Pod	`apps`	`10.244.2.5`
`web-service` Service	`apps`	`10.107.37.188`

Service DNS Records

When a Service is created, Kubernetes DNS creates a DNS record for it.

Example:

Service Name: web-service
Namespace: apps
Service IP: 10.107.37.188

DNS record:

web-service.apps.svc.cluster.local → 10.107.37.188

Note

Service DNS records are created automatically.

Same Namespace Service Access

If a Pod and Service are in the same namespace, the Pod can use the short Service name.

Example:

curl http://web-service

This works when both are in the same namespace.

Example

A Pod in the apps namespace can reach the web-service Service in the apps namespace using only web-service.

Cross-Namespace Service Access

If the client Pod is in another namespace, use:

<service-name>.<namespace>

Example:

curl http://web-service.apps

Tip

Use service.namespace when accessing a Service across namespaces.

Fully Qualified Domain Name

The full DNS name for a Service is:

<service-name>.<namespace>.svc.cluster.local

Example:

curl http://web-service.apps.svc.cluster.local

Breakdown:

Part	Meaning
`web-service`	Service name
`apps`	Namespace
`svc`	Service subdomain
`cluster.local`	Cluster DNS root domain

Success

The fully qualified DNS name works from anywhere inside the cluster.

Service DNS Name Formats

For a Service named web-service in namespace apps:

DNS Name	Works From
`web-service`	Same namespace
`web-service.apps`	Any namespace
`web-service.apps.svc`	Any namespace
`web-service.apps.svc.cluster.local`	Any namespace

Tip

In production manifests and application configs, prefer explicit names like web-service.apps.svc.cluster.local when clarity is important.

DNS Domain Structure

Kubernetes DNS structure:

cluster.local
└── svc
    └── apps
        └── web-service

Full name:

web-service.apps.svc.cluster.local

Note

cluster.local is the default root domain, but it can be customized during cluster setup.

Pod DNS Records

Pod DNS records are different from Service DNS records.

For Pods, Kubernetes can generate DNS names by replacing dots in the Pod IP with dashes.

Example Pod:

Pod IP: 10.244.2.5
Namespace: apps

Pod DNS name:

10-244-2-5.apps.pod.cluster.local

Warning

Pod DNS records are not always enabled by default. Service DNS records are the normal and recommended discovery method.

Pod DNS Name Format

Pod DNS format:

<pod-ip-with-dashes>.<namespace>.pod.cluster.local

Example:

10-244-2-5.apps.pod.cluster.local

This resolves to:

10.244.2.5

Danger

Avoid designing applications around Pod DNS names because Pods are temporary and can be replaced.

Service DNS vs Pod DNS

Feature	Service DNS	Pod DNS
Created automatically	Yes	Depends on configuration
Stable	Yes	No
Recommended for apps	Yes	Usually no
Example	`web-service.apps.svc.cluster.local`	`10-244-2-5.apps.pod.cluster.local`
Resolves to	Service IP	Pod IP

Success

Use Service DNS for application-to-application communication.

Example Service Access

From a test Pod:

curl http://web-service

If Service is in another namespace:

curl http://web-service.apps

Using full name:

curl http://web-service.apps.svc.cluster.local

Expected output:

Welcome to NGINX!

How Kubernetes DNS Works

High-level flow:

Pod sends DNS query
      ↓
CoreDNS receives query
      ↓
CoreDNS checks Kubernetes records
      ↓
Service name resolves to ClusterIP
      ↓
Pod connects to Service IP
      ↓
kube-proxy forwards traffic to backend Pod

Note

DNS only resolves the name to an IP. Traffic forwarding is handled by Service networking and kube-proxy.

DNS and Services

A Service provides:

stable name
stable ClusterIP
backend Pod selection
load distribution through kube-proxy rules

DNS maps the Service name to its ClusterIP.

Example:

web-service.apps.svc.cluster.local → 10.107.37.188

Tip

DNS and Services work together. DNS gives the name; Service networking forwards traffic.

Production Best Practices

Recommended

Use Service DNS names instead of Pod IPs
Use namespaces to separate environments
Prefer explicit cross-namespace names
Keep Service names meaningful and stable
Monitor CoreDNS health
Scale CoreDNS for large clusters
Avoid hardcoding ClusterIPs in applications
Use readiness probes so Services route only to healthy Pods

Do's

Use service-name.namespace for cross-namespace access
Use full FQDN when troubleshooting
Check CoreDNS Pods in kube-system
Validate Service and Endpoints
Use Services for stable application discovery
Keep namespace names clear and environment-specific

Don'ts

Don't hardcode Pod IPs
Don't rely on Pod DNS for stable application access
Don't use the same Service names ambiguously across namespaces without understanding DNS search behavior
Don't ignore CoreDNS errors
Don't assume DNS is broken before checking Service endpoints
Don't expose databases through DNS names without proper NetworkPolicy and RBAC controls

Danger

DNS failures can make applications appear down even when Pods and Services are running.

Troubleshooting DNS

When DNS resolution fails, check:

Is CoreDNS running?
Is the Service created?
Does the Service have a ClusterIP?
Are Endpoints created?
Are backend Pods Ready?
Is the client Pod in the expected namespace?
Are you using the correct DNS name format?
Is /etc/resolv.conf configured correctly inside the Pod?
Are NetworkPolicies blocking DNS traffic?

Useful Commands

Check Services:

kubectl get svc -A

Check Endpoints:

kubectl get endpoints -A

Check CoreDNS Pods:

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

Check CoreDNS logs:

kubectl logs -n kube-system -l k8s-app=kube-dns

Run DNS lookup from a test Pod:

kubectl run -it --rm dns-test --image=busybox:1.28 -- nslookup web-service.apps

Test full FQDN:

kubectl run -it --rm dns-test --image=busybox:1.28 -- nslookup web-service.apps.svc.cluster.local

Check Pod resolver config:

kubectl exec <pod-name> -- cat /etc/resolv.conf

DNS Search Behavior

Pods usually have search domains configured in /etc/resolv.conf.

Example:

search default.svc.cluster.local svc.cluster.local cluster.local

This allows short names like:

web-service

to be expanded automatically.

Warning

Search domains depend on the Pod namespace. Cross-namespace access should use at least service.namespace.

DNS and Namespaces

Namespace matters.

Example:

Client Namespace	Service Namespace	Recommended Name
`apps`	`apps`	`web-service`
`default`	`apps`	`web-service.apps`
any namespace	`apps`	`web-service.apps.svc.cluster.local`

Tip

Use the fully qualified name when debugging to remove namespace search ambiguity.

Security Considerations

DNS itself does not enforce access control.

Use these controls for production security:

NetworkPolicies
RBAC
namespace isolation
service account permissions
admission policies
private Services for internal workloads

Danger

If a Pod can resolve a Service name and network policies allow traffic, it may be able to connect. DNS is not a security boundary.

Summary

Quote

Kubernetes DNS provides internal service discovery
Services get DNS records automatically
Same-namespace Services can be reached by short name
Cross-namespace Services use service.namespace
Full Service DNS is service.namespace.svc.cluster.local
Pod DNS can exist but is not recommended for stable app communication
Use Services and DNS together for reliable Kubernetes networking