CoreDNS - The Phone Book of Your Kubernetes Cluster
What is CoreDNS in Simple Terms?
Without CoreDNS, your pods would need to hardcode IP addresses to talk to each other ā and pod IPs change every time a pod restarts. CoreDNS is the phone book of your cluster: you call orders-service and CoreDNS looks up its current IP and routes you there automatically.
How DNS Resolution Works Step by Step
ā DIAGRAM
+--------------------------------------------------+| Pod calls: orders-service.production.svc.cluster.local | <- Step 1: DNS query+--------------------------------------------------+ | v+--------------------------------------------------+| Pod's /etc/resolv.conf points to CoreDNS | <- Step 2: Resolver config| nameserver 10.96.0.10 (CoreDNS ClusterIP) |+--------------------------------------------------+ | v+--------------------------------------------------+| CoreDNS receives query, looks up Service in etcd | <- Step 3: Lookup+--------------------------------------------------+ | v+--------------------------------------------------+| CoreDNS returns ClusterIP: 10.96.45.200 | <- Step 4: Response+--------------------------------------------------+ | v+--------------------------------------------------+| kube-proxy routes traffic to a healthy pod | <- Step 5: Delivery+--------------------------------------------------+Kubernetes DNS Name Format
Bash
1# Full DNS name format for any Service2<service-name>.<namespace>.svc.cluster.local3 4# Production examples5payments-service.production.svc.cluster.local6redis.cache.svc.cluster.local7postgres-0.postgres.production.svc.cluster.local # StatefulSet pod DNS8 9# Short names also work within the same namespace10# From inside the production namespace:11curl http://payments-service:4000/health # works12curl http://payments-service.production:4000/health # works13curl http://payments-service.production.svc.cluster.local:4000/health # always worksCoreDNS Architecture Inside the Cluster
ā DIAGRAM
+-------------------------------+ +-------------------------------+| kube-system ns | | production ns || | | || coredns pod 1 (10.244.0.5) | | payments-api pod || coredns pod 2 (10.244.0.6) | <------> | /etc/resolv.conf: || | | nameserver 10.96.0.10 || CoreDNS Service | | search production.svc... || ClusterIP: 10.96.0.10 | | |+-------------------------------+ +-------------------------------+CoreDNS runs as 2 replicas by default for HA. All pods in the cluster are configured at creation time to point to the CoreDNS ClusterIP for DNS resolution.
CoreDNS Configuration (Corefile)
Bash
1# View the active CoreDNS config2kubectl get configmap coredns -n kube-system -o yaml
YAML
1# Default Corefile inside the ConfigMap2apiVersion: v13kind: ConfigMap4metadata:5 name: coredns6 namespace: kube-system7data:8 Corefile: |9 .:53 {10 errors11 health {12 lameduck 5s13 }14 ready15 kubernetes cluster.local in-addr.arpa ip6.arpa {16 pods insecure17 fallthrough in-addr.arpa ip6.arpa18 ttl 3019 }20 prometheus :9153 # Metrics endpoint for Grafana/Prometheus21 forward . /etc/resolv.conf # Forwards external DNS queries upstream22 cache 3023 loop24 reload25 loadbalance26 }Debugging CoreDNS Issues
Bash
1# Check CoreDNS pods are running and healthy2kubectl get pods -n kube-system -l k8s-app=kube-dns3 4# Check CoreDNS logs for query failures or errors5kubectl logs -n kube-system -l k8s-app=kube-dns --tail=506 7# Run a debug pod with full DNS tools8kubectl run dns-debug --image=busybox:1.35 -it --rm -n production -- sh9 10# Inside the debug pod ā test resolution11nslookup payments-service.production.svc.cluster.local12nslookup kubernetes.default.svc.cluster.local13 14# Test cross-namespace resolution15nslookup redis.cache.svc.cluster.local16 17# Check what DNS config a pod received18kubectl exec -it <pod-name> -n production -- cat /etc/resolv.confTroubleshooting CoreDNS Issues
| Symptom | Likely Cause | Fix |
|---|---|---|
nslookup times out inside pod |
CoreDNS pods not running | kubectl get pods -n kube-system ā check coredns pods |
| Short name works, FQDN fails | Search domain misconfigured | Check /etc/resolv.conf inside the pod |
| Cross-namespace call fails | Using short name instead of FQDN | Use service.namespace.svc.cluster.local |
| DNS works for some pods, not others | CoreDNS overloaded | Scale CoreDNS replicas up |
| External DNS not resolving | Upstream forwarder misconfigured | Check forward directive in Corefile |
Bash
1# Scale CoreDNS for high-traffic clusters (Hotstar/Swiggy scale)2kubectl scale deployment coredns --replicas=4 -n kube-system3 4# Restart CoreDNS if config was updated5kubectl rollout restart deployment/coredns -n kube-system6 7# Watch CoreDNS pod status during restart8kubectl rollout status deployment/coredns -n kube-systemš“ Common Mistake: Using short service names for cross-namespace calls.orders-serviceresolves correctly only from within the same namespace. From a different namespace, it silently fails or hits the wrong service. Always use the full FQDNorders-service.production.svc.cluster.localfor cross-namespace communication ā especially critical in Swiggy or Razorpay-scale microservice environments with 50+ namespaces.
š” Tip: If pods cannot resolve DNS, check CoreDNS logs first with kubectl logs -n kube-system -l k8s-app=kube-dns. DNS failures are one of the most common root causes of mysterious service connectivity issues in Kubernetes ā they look like network errors but are actually name resolution failures.š Remember: CoreDNS is itself a Kubernetes Service with a ClusterIP (default10.96.0.10). Every pod's/etc/resolv.confis automatically configured by kubelet to point to this address at creation time. If CoreDNS goes down, the entire cluster's service discovery breaks ā treat it as a critical infrastructure component, not just another deployment.
ā ļø Security: CoreDNS can be configured to block internal DNS queries to prevent pods from discovering services they shouldn't. In multi-tenant clusters at PhonePe or CRED, use CoreDNS policy plugins combined with NetworkPolicy to restrict which namespaces can resolve which service names.