🧠 Kubernetes DNS Demystified — How Pods Talk Using Names Instead of IPs

Kubernetes is known for its powerful service discovery mechanism. Ever wondered how a pod like frontend magically connects to backend.default.svc.cluster.local without knowing its IP?

Let’s break down the role of CoreDNS, the resolv.conf file, and how Kubernetes networking makes all this possible.

---

🧩 1. Every Pod Has a DNS Configuration

When a pod is created in Kubernetes, it automatically gets a file at:

/etc/resolv.conf

This file looks something like:

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

🔍 What Does This Do?

• nameserver 10.96.0.10: This is the ClusterIP of the CoreDNS service in the kube-system namespace.

• All DNS queries from the pod go through this internal DNS server.

---

📦 2. What is CoreDNS?

CoreDNS is Kubernetes’ internal DNS server. It runs as a deployment under the kube-system namespace and usually has 2+ pods for high availability.

You can check it with:

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

CoreDNS is backed by a ConfigMap named coredns, which contains its behavior settings:

53 {
    errors
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
        ttl 30
    }
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
}

---

🔗 3. How DNS Works Inside Kubernetes

Let’s say PodA wants to talk to myapp.default.svc.cluster.local.

Here’s what happens:

1. PodA checks /etc/resolv.conf and sends a DNS query to 10.96.0.10 (CoreDNS).

2. CoreDNS checks if this name exists using its Kubernetes plugin, which queries the Kubernetes API.

3. If the service myapp exists, CoreDNS returns its ClusterIP.

4. PodA then talks directly to that IP.

🔁 This makes communication dynamic and resilient — even if the actual pod behind myapp changes, DNS will always resolve the correct IP.

---

🌍 4. What About External Domains?

Want to curl google.com from your pod? That works too.

When CoreDNS doesn’t recognize a domain, it uses this line:

coredns . /etc/resolv.conf

This means:

• Forward unknown requests to the host node’s DNS resolver.

• Typically, this is your cloud provider’s or system DNS like 8.8.8.8.

• So external names like google.com get resolved just like on a regular machine.

---

🛠️ Real-World Example

$ kubectl exec -it mypod -- cat /etc/resolv.conf

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local

If you curl myapp.default.svc.cluster.local, it goes like this:

1. DNS query → CoreDNS

2. CoreDNS → Kubernetes API → finds service

3. CoreDNS replies with IP (e.g., 10.244.1.12)

4. Pod connects to IP directly

---

🧠 TL;DR

---

🎯 Final Thoughts

Kubernetes DNS is one of those invisible-yet-critical systems. CoreDNS, backed by the Kubernetes API, enables microservices to communicate reliably — even if pods move, restart, or scale dynamically.

Understanding this system helps debug networking issues and build more resilient clusters.