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.