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.

Practice

1. What is the main role of CoreDNS in a Kubernetes cluster?

easy

A. To manage container images in the cluster

B. To provide DNS resolution for services and pods inside the cluster

C. To schedule pods on nodes

D. To monitor cluster resource usage

Solution

1. Step 1: Understand CoreDNS function

   CoreDNS acts as the DNS server inside Kubernetes, resolving names of services and pods.

2. Step 2: Compare with other options

   Managing images, scheduling pods, and monitoring are done by other components like container registries, kube-scheduler, and metrics servers.

3. Final Answer:

   To provide DNS resolution for services and pods inside the cluster -> Option B

4. Quick Check:

   CoreDNS = DNS resolution inside Kubernetes [OK]

Hint: CoreDNS is Kubernetes' internal DNS server [OK]

Common Mistakes:

• Confusing CoreDNS with pod scheduling
• Thinking CoreDNS manages container images
• Assuming CoreDNS monitors resources

2. Which Kubernetes resource holds the CoreDNS configuration?

easy

A. Secret named coredns in default namespace

B. Deployment in kube-system namespace

C. ConfigMap named coredns in kube-system namespace

D. ServiceAccount named coredns in kube-system namespace

Solution

1. Step 1: Identify CoreDNS configuration storage

   The CoreDNS configuration is stored in a ConfigMap named 'coredns' inside the 'kube-system' namespace.

2. Step 2: Eliminate other options

   Deployment runs CoreDNS pods but does not hold config; Secrets store sensitive data; ServiceAccounts manage permissions.

3. Final Answer:

   ConfigMap named coredns in kube-system namespace -> Option C

4. Quick Check:

   CoreDNS config = ConfigMap coredns in kube-system [OK]

Hint: CoreDNS config is a ConfigMap in kube-system [OK]

Common Mistakes:

• Confusing ConfigMap with Secret
• Looking in default namespace instead of kube-system
• Thinking Deployment holds config data

3. Inside a pod, you run nslookup kubernetes.default.svc.cluster.local. What is the expected result?

medium

A. An IP address of the Kubernetes API service

B. An error saying domain not found

C. The pod's own IP address

D. The IP address of the CoreDNS pod

Solution

1. Step 1: Understand the DNS query

   The domain 'kubernetes.default.svc.cluster.local' is the default Kubernetes API service DNS name inside the cluster.

2. Step 2: Determine expected DNS resolution

   CoreDNS resolves this to the IP address of the Kubernetes API service, not the pod or CoreDNS pod IP.

3. Final Answer:

   An IP address of the Kubernetes API service -> Option A

4. Quick Check:

   Default service DNS resolves to API server IP [OK]

Hint: Default service DNS resolves to API server IP [OK]

Common Mistakes:

• Expecting pod IP instead of service IP
• Assuming CoreDNS pod IP is returned
• Thinking query fails inside pod

4. You modified the CoreDNS ConfigMap but DNS queries inside pods still fail. What is the most likely fix?

medium

A. Restart the CoreDNS pods to reload the new config

B. Delete all pods in the default namespace

C. Reinstall Kubernetes cluster

D. Change pod DNSPolicy to Default

Solution

1. Step 1: Recognize CoreDNS config reload behavior

   CoreDNS pods need to reload the ConfigMap changes, which usually requires restarting the pods.

2. Step 2: Evaluate other options

   Deleting unrelated pods or reinstalling the cluster is unnecessary; changing DNSPolicy may break cluster DNS.

3. Final Answer:

   Restart the CoreDNS pods to reload the new config -> Option A

4. Quick Check:

   CoreDNS pods restart reloads ConfigMap changes [OK]

Hint: Restart CoreDNS pods after ConfigMap changes [OK]

Common Mistakes:

• Deleting unrelated pods expecting DNS fix
• Reinstalling cluster unnecessarily
• Changing pod DNSPolicy incorrectly

5. You want to add a custom DNS entry for myapp.local inside your Kubernetes cluster using CoreDNS. Which step is required?

hard

A. Deploy a pod named myapp.local with a static IP

B. Create a new Service named myapp.local in default namespace

C. Modify the kubelet to add myapp.local to /etc/hosts on all nodes

D. Add a hosts plugin entry in the CoreDNS ConfigMap with myapp.local mapping

Solution

1. Step 1: Understand how to add custom DNS entries in CoreDNS

   CoreDNS supports a hosts plugin where you can add static hostname-to-IP mappings in its ConfigMap.

2. Step 2: Evaluate other options

   Creating a Service named myapp.local won't create a DNS entry for that domain; modifying kubelet hosts is manual and not scalable; pod names don't create DNS entries.

3. Final Answer:

   Add a hosts plugin entry in the CoreDNS ConfigMap with myapp.local mapping -> Option D

4. Quick Check:

   Custom DNS via hosts plugin in CoreDNS ConfigMap [OK]

Hint: Use hosts plugin in CoreDNS ConfigMap for custom DNS [OK]

Common Mistakes:

• Thinking Service name creates arbitrary DNS names
• Modifying node hosts files manually
• Assuming pod names create DNS entries