How Does DNS Resolution Work Inside Kubernetes?
Learn how Kubernetes Service DNS names resolve via CoreDNS, including headless Services and how DNS hides Pod IP churn.
Expected Interview Answer
Kubernetes gives every Service a stable, cluster-internal DNS name in the form service.namespace.svc.cluster.local, resolved by an in-cluster DNS server (CoreDNS by default) so Pods can reach each other by name instead of by ephemeral IP address.
Every Pod’s /etc/resolv.conf is configured by the kubelet to point at the cluster DNS Service’s ClusterIP, with a search path that lets short names like myservice resolve within the same namespace before falling back to the fully qualified form. When a Pod queries a Service name, CoreDNS looks up the corresponding Service object and returns either the Service’s stable ClusterIP (for standard Services) or the individual Pod IPs (for headless Services, useful for StatefulSets that need per-Pod addressing). CoreDNS runs as a Deployment inside the cluster itself, watches the Kubernetes API for Service and Endpoint changes, and updates its records dynamically so DNS always reflects the current state without manual updates. This decouples application code from Pod IP churn entirely, since a Pod can restart with a new IP but the Service DNS name it sits behind never changes.
- Stable service names abstract away ephemeral Pod IP churn
- Namespace-scoped short names simplify in-cluster service calls
- CoreDNS updates records automatically as Services and Endpoints change
- Headless Services expose individual Pod DNS entries for stateful workloads
AI Mentor Explanation
DNS in Kubernetes is like a stadium directory that lets a fan ask for "Team A dressing room" and get routed to whichever physical room the team is using that day, even if the room assignment changes between matches. The stadium’s central desk (CoreDNS) tracks the current room assignment and updates it the moment logistics reassigns rooms, so nobody needs to memorize a room number that could change tomorrow. A fan asking just “dressing room” within their own stand gets a shorter, local answer, while asking with the full venue-and-city name works from anywhere. This is why players and staff can always be found by role, never by a room number that might be reused for someone else next week.
Step-by-Step Explanation
Step 1
kubelet configures resolv.conf
Each Pod is set up to send DNS queries to the cluster DNS Service’s ClusterIP, with a namespace search path.
Step 2
Query hits CoreDNS
CoreDNS receives the query and checks its in-memory zone data built from the Kubernetes API.
Step 3
Resolve against Service/Endpoints
CoreDNS returns the Service’s stable ClusterIP, or individual Pod IPs for a headless Service.
Step 4
Records stay live
CoreDNS watches the API server for Service and Endpoint changes and updates records without any manual step.
What Interviewer Expects
- Knowledge of the service.namespace.svc.cluster.local naming convention
- Understanding that CoreDNS is the default in-cluster DNS server watching the API
- Awareness of the difference between a normal Service DNS entry and a headless Service
- Ability to explain how DNS decouples applications from Pod IP churn
Common Mistakes
- Hardcoding Pod IPs instead of using Service DNS names
- Confusing ClusterIP resolution with headless Service Pod-level resolution
- Not knowing CoreDNS itself runs as Pods that can be scaled or debugged like any workload
- Forgetting the namespace search path affects how short names resolve
Best Answer (HR Friendly)
“Inside Kubernetes, every service gets a predictable DNS name, so our code just calls that name instead of tracking IP addresses that change whenever a pod restarts. CoreDNS runs inside the cluster and constantly watches for service changes, updating its records automatically, which means our applications stay decoupled from the underlying infrastructure churn.”
Code Example
apiVersion: v1
kind: Service
metadata:
name: orders-api
namespace: backend
spec:
selector:
app: orders-api
ports:
- port: 80
targetPort: 8080
# From a pod in the same namespace: curl http://orders-api
# From any namespace: curl http://orders-api.backend.svc.cluster.localFollow-up Questions
- What is the difference between a normal Service and a headless Service in DNS terms?
- How would you debug a Pod that cannot resolve a Service name?
- What happens to DNS if CoreDNS Pods become unavailable?
- How does DNS caching (like NodeLocal DNSCache) improve performance in large clusters?
MCQ Practice
1. What is the default in-cluster DNS server in modern Kubernetes?
CoreDNS is the default cluster DNS server, watching the Kubernetes API and serving records dynamically.
2. What does a headless Service return in DNS?
A headless Service (clusterIP: None) returns the individual Pod IPs directly instead of one virtual ClusterIP.
3. Why can applications inside Kubernetes call a Service by name instead of by IP?
CoreDNS keeps Service DNS names resolving correctly even as underlying Pod IPs change, decoupling code from IP churn.
Flash Cards
What is a Service’s full DNS name format? — service.namespace.svc.cluster.local
What runs cluster DNS by default? — CoreDNS, deployed as Pods inside the cluster itself.
How does CoreDNS stay up to date? — It watches the Kubernetes API for Service and Endpoint changes.
What does a headless Service expose in DNS? — Individual Pod IPs instead of one ClusterIP, used by StatefulSets.