DNS in Kubernetes (CoreDNS) - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

CoreDNS Pod DNS Resolution Output

You run the command kubectl exec -it coredns-abc123 -- nslookup kubernetes.default. What is the expected output?

A

Server: 10.96.0.10
Address: 10.96.0.10#53

Name: kubernetes.default.svc.cluster.local
Address: 10.96.0.1

B Error: unable to resolve host kubernetes.default

C

Server: 8.8.8.8
Address: 8.8.8.8#53

Name: kubernetes.default
Address: 8.8.8.8

D

Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find kubernetes.default: NXDOMAIN

💡 Hint

CoreDNS runs inside the cluster and resolves cluster DNS names using the cluster DNS IP.

The CoreDNS pod uses the cluster DNS IP (usually 10.96.0.10) to resolve internal Kubernetes service names like kubernetes.default. The response includes the full DNS name and the cluster IP of the Kubernetes API server.

❓ Configuration

intermediate

CoreDNS ConfigMap Block for Forwarding External DNS

Which CoreDNS ConfigMap snippet correctly forwards external DNS queries to 8.8.8.8?

A

.:53 {
    forward 8.8.8.8
    errors
    cache 30
}

B

.:53 {
    proxy . 8.8.8.8
    errors
    cache 30
}

C

.:53 {
    forward . 8.8.8.8:53
    errors
    cache 30
}

D

.:53 {
    forward . 8.8.8.8
    errors
    cache 30
}

💡 Hint

The 'forward' plugin requires the domain '.' and the IP address of the DNS server.

The correct CoreDNS forwarding block uses the 'forward' plugin with the domain '.' to forward all external DNS queries to 8.8.8.8. The 'proxy' plugin is deprecated. The IP must be specified after the domain.

❓ Troubleshoot

advanced

CoreDNS Fails to Resolve Internal Service Names

You notice pods cannot resolve internal service names like myservice.default.svc.cluster.local. Which is the most likely cause?

A The external DNS server 8.8.8.8 is unreachable

B CoreDNS pods are not running or CrashLoopBackOff

C The pod's /etc/resolv.conf points to 127.0.0.1

D The service has no endpoints

💡 Hint

CoreDNS must be healthy to resolve cluster DNS names.

If CoreDNS pods are not running or crashing, DNS resolution inside the cluster fails for internal service names. External DNS issues or service endpoints do not affect CoreDNS resolving service names.

🔀 Workflow

advanced

Steps to Update CoreDNS ConfigMap and Apply Changes

What is the correct sequence to update CoreDNS ConfigMap and apply changes in Kubernetes?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Edit first, then restart pods, then verify and test.

First edit the ConfigMap to update CoreDNS settings. Then restart the CoreDNS deployment to apply changes. After pods restart and become ready, test DNS resolution inside a pod to confirm success.

✅ Best Practice

expert

Best Practice for CoreDNS High Availability

Which option describes the best practice to ensure CoreDNS high availability in a Kubernetes cluster?

A Disable CoreDNS and use external DNS servers only

B Run a single CoreDNS pod on the master node only

C Run multiple CoreDNS replicas across different nodes with PodDisruptionBudgets

D Run CoreDNS pods without resource limits to maximize performance

💡 Hint

High availability means no single point of failure and controlled disruptions.

Running multiple CoreDNS replicas distributed across nodes with PodDisruptionBudgets ensures DNS service remains available during node failures or upgrades. Single pods or disabling CoreDNS reduce availability. Resource limits prevent resource exhaustion.

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