DNS

Understand Kubernetes DNS, CoreDNS, service names, namespace-qualified lookup, and debugging service discovery.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: Kubernetes DNS gives Services and Pods discoverable names. Most apps call Services by DNS name instead of Pod IP.

🔍 What Is It?

Kubernetes DNS is cluster service discovery, commonly implemented by CoreDNS.

It creates DNS records for Services and supports namespace-qualified names such as orders-api.orders-prod.svc.cluster.local.

🎯 Why Do We Need It?

Applications need stable names for dependencies. DNS lets Pods discover Services even as Pod IPs and endpoints change.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A checkout service in the web namespace calls orders-api.orders-prod.svc.cluster.local for order creation. Platform teams monitor CoreDNS latency, cache behavior, and error rates because DNS problems look like application outages.

⚙️ How It Works

CoreDNS runs in the cluster and watches Kubernetes Service and EndpointSlice data. Pods receive DNS configuration so short names, namespace names, and fully qualified service names resolve inside the cluster.

💻 Example

Service DNS names — Common DNS forms inside a cluster.

text
Same namespace:
  http://orders-api

Different namespace:
  http://orders-api.orders-prod

Fully qualified:
  http://orders-api.orders-prod.svc.cluster.local

Debug:
  kubectl exec -n web deploy/frontend -- nslookup orders-api.orders-prod

🤔 Common Confusions

❓ Should apps use Pod IPs?

No. Pod IPs are ephemeral. Use Service DNS names.

❓ Why does a short service name fail?

Short names resolve in the caller namespace. Use namespace-qualified names for cross-namespace calls.

❓ Is CoreDNS optional?

Cluster DNS is foundational for most Kubernetes workloads. CoreDNS is the common implementation.

🚨 Common Production Issues

**CoreDNS under-provisioned** causes intermittent service lookup failures.

**Cross-namespace short names** point to the wrong namespace or fail.

**DNS search path surprises** add latency or ambiguity.

**No DNS monitoring** makes service discovery issues hard to identify.

✅ Best Practices

Use Service DNS names instead of Pod IPs

Use namespace-qualified names for cross-namespace traffic

Monitor CoreDNS latency, errors, and saturation

Scale CoreDNS appropriately for cluster size

Include DNS checks in network troubleshooting runbooks

🏛️ Architect's Note

Senior Architect's Perspective

DNS is invisible until it fails. In Kubernetes, service discovery is only as reliable as CoreDNS and the naming practices teams follow.

💬 Frequently Asked Questions

Interview: How would you explain DNS in a real Kubernetes project?

DNS should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with DNS?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1Kubernetes DNS supports Service discovery
2CoreDNS is production-critical
3Cross-namespace calls should be explicit
4DNS issues often look like app or network failures

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.