Introduction

Not in the sense of treating Kubernetes DNS like a general-purpose DNS control panel. Legacy kube-dns was designed mainly for service discovery, not for ad hoc management of arbitrary static records. In modern clusters, the practical solution is usually CoreDNS configuration, zone forwarding, or external DNS management rather than trying to stuff custom records directly into kube-dns.

First Check What DNS Component the Cluster Actually Uses

Many people still say kube-dns even when the cluster is really running CoreDNS. That matters because CoreDNS is much more flexible.

kubectl -n kube-system get deployment -l k8s-app=kube-dns
kubectl -n kube-system get deployment -l k8s-app=coredns

If CoreDNS is present, that is the real place to make changes. Applying old kube-dns assumptions to a CoreDNS cluster usually wastes time.

What kube-dns Was Designed to Do

kube-dns was built mainly to resolve internal Kubernetes names such as:

• services inside the cluster
• pod-related DNS forms supported by the cluster setup
• forwarded external names through limited configuration

It was not designed as a full arbitrary record management system where operators casually create A, AAAA, TXT, or CNAME records by hand. That is why the direct answer is usually “use a different layer.”

Static Records in CoreDNS

If your cluster uses CoreDNS and you only need a small number of fixed names, the hosts plugin is often the simplest option.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: coredns
5  namespace: kube-system
6data:
7  Corefile: |
8    .:53 {
9        errors
10        health
11        hosts {
12            10.10.0.15 internal-api.local
13            10.10.0.20 payments.local
14            fallthrough
15        }
16        kubernetes cluster.local in-addr.arpa ip6.arpa
17        forward . /etc/resolv.conf
18        cache 30
19        reload
20    }

After updating the ConfigMap, reload or restart CoreDNS if needed:

kubectl -n kube-system rollout restart deployment/coredns

This works well for a few controlled mappings, but it does not scale like a real authoritative DNS workflow.

Forward a Zone to External DNS

If the records already belong in another DNS system, forwarding is usually cleaner than copying them into cluster DNS.

1example.internal:53 {
2    forward . 10.0.0.2 10.0.0.3
3    cache 60
4}

This keeps authoritative records in one place and lets the cluster resolver focus on resolution, not ownership.

Use ExternalDNS for Kubernetes-Driven Records

If the real goal is to create DNS names from Kubernetes objects, ExternalDNS is often the better answer.

1apiVersion: v1
2kind: Service
3metadata:
4  name: api
5  annotations:
6    external-dns.alpha.kubernetes.io/hostname: api.example.com
7spec:
8  type: LoadBalancer
9  selector:
10    app: api
11  ports:
12    - port: 80
13      targetPort: 8080

In this design, Kubernetes objects declare the desired hostnames, but the authoritative records still live in a proper DNS provider such as Route 53, Cloud DNS, or Cloudflare.

If the Cluster Really Still Uses kube-dns

Legacy kube-dns supported some stub domain and upstream behavior, but it was never as flexible as CoreDNS. If you need frequent custom records, plugin-style extensibility, or richer DNS policy, migration to CoreDNS is usually the stronger long-term answer.

Treat kube-dns customization as legacy maintenance, not as a modern DNS platform.

Common Pitfalls

The most common mistake is assuming kube-dns is a general-purpose DNS authoring system.

Another pitfall is editing running DNS pods directly instead of changing supported configuration objects such as the CoreDNS ConfigMap. Developers also often duplicate authoritative external records inside cluster DNS unnecessarily, which creates drift and makes troubleshooting harder.

Finally, teams sometimes reach for custom DNS entries when the real need is service discovery through native Kubernetes Services or an ingress hostname managed by ExternalDNS.

Summary

• Legacy kube-dns is not a good place to manage arbitrary custom records directly.
• In modern clusters, CoreDNS is usually the actual configuration target.
• Use static CoreDNS records only for a small number of controlled internal names.
• Forward zones when another DNS system is authoritative.
• Use ExternalDNS when hostnames should be driven by Kubernetes resources automatically.