DNS in Kubernetes (CoreDNS) - Step-by-Step Execution

Process Flow - DNS in Kubernetes (CoreDNS)

Pod sends DNS query

↓

CoreDNS receives query

↓

CoreDNS checks local cache

↓

Return cached IP

No↓

CoreDNS queries Kubernetes API

↓

CoreDNS resolves service/pod name

↓

CoreDNS returns IP to Pod

↓

Pod connects to resolved IP

This flow shows how a Pod's DNS query is handled by CoreDNS in Kubernetes, resolving service or pod names to IP addresses.

Execution Sample

Kubernetes

kubectl run busybox --image=busybox --restart=Never -- sleep 3600
kubectl exec busybox -- nslookup kubernetes.default
kubectl get svc kubernetes -o jsonpath='{.spec.clusterIP}'

This sequence runs a busybox pod, performs a DNS lookup for the Kubernetes service, and retrieves the service IP to verify DNS resolution.

Process Table

Step	Action	Input/Query	CoreDNS Behavior	Output/Result
1	Pod starts and sends DNS query	nslookup kubernetes.default	CoreDNS receives query	Query received for kubernetes.default
2	CoreDNS checks cache	kubernetes.default	No cached entry found	Cache miss
3	CoreDNS queries Kubernetes API	Request service IP for kubernetes.default	API returns cluster IP	10.96.0.1
4	CoreDNS caches result	kubernetes.default -> 10.96.0.1	Stores IP in cache	Cache updated
5	CoreDNS returns IP to Pod	10.96.0.1	Pod receives IP	nslookup output shows 10.96.0.1
6	Pod connects to service	Connect to 10.96.0.1	Connection established	Service reachable
7	Pod sends repeated DNS query	nslookup kubernetes.default	CoreDNS checks cache	Cache hit, returns 10.96.0.1
8	Pod sends DNS query for unknown name	nslookup unknown.svc.cluster.local	CoreDNS checks cache and API	Name not found error
9	Exit	No more queries	End of DNS resolution process	Process complete

💡 DNS queries stop or unknown names cause resolution failure

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 7	Final
Cache	empty	{'kubernetes.default': '10.96.0.1'}	{'kubernetes.default': '10.96.0.1'}	{'kubernetes.default': '10.96.0.1'}	{'kubernetes.default': '10.96.0.1'}
Pod DNS Query	none	kubernetes.default	kubernetes.default	kubernetes.default	unknown.svc.cluster.local
Resolved IP	none	10.96.0.1	10.96.0.1	10.96.0.1	none

Key Moments - 3 Insights

Why does CoreDNS query the Kubernetes API after a cache miss?

Because CoreDNS does not have the IP cached, it must ask the Kubernetes API to get the current IP for the service name, as shown in step 3 of the execution_table.

What happens when a Pod queries a DNS name that does not exist?

CoreDNS tries to find the name in cache and API but fails, returning a name not found error, as shown in step 8 of the execution_table.

How does caching improve DNS query performance in Kubernetes?

Caching stores resolved IPs so repeated queries return immediately without API calls, demonstrated by the cache hit in step 7.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What does CoreDNS do after a cache miss?

A Queries the Kubernetes API for the service IP

B Returns an error immediately

C Sends the query to an external DNS server

D Ignores the query

💡 Hint

Refer to the 'CoreDNS Behavior' column at step 3 in the execution_table

At which step does CoreDNS cache the resolved IP address?

A Step 2

B Step 4

C Step 6

D Step 8

💡 Hint

Look for the step where 'CoreDNS caches result' in the 'Action' column

If the Pod queries 'unknown.svc.cluster.local', what will CoreDNS return?

A The IP address of the Kubernetes service

B A cached IP from previous queries

C A name not found error

D The IP of the Pod itself

💡 Hint

Check the 'Output/Result' column at step 8 in the execution_table

Concept Snapshot

DNS in Kubernetes uses CoreDNS to resolve service and pod names.
Pods send DNS queries to CoreDNS.
CoreDNS checks cache first, then Kubernetes API if needed.
Resolved IPs are cached for faster future queries.
Unknown names return errors.
This enables service discovery inside the cluster.

Full Transcript

In Kubernetes, DNS resolution is handled by CoreDNS. When a Pod sends a DNS query, CoreDNS first checks its cache. If the IP is not cached, CoreDNS queries the Kubernetes API to get the IP address of the requested service or pod. It then caches this IP for future queries. The Pod receives the IP and can connect to the service. If the DNS name does not exist, CoreDNS returns a name not found error. This process allows Pods to discover services by name within the cluster efficiently.