Before Kubernetes enters the picture, let us understand the plain idea of DNS.

The Phone Book of the Internet

DNS stands for Domain Name System. Computers talk to each other using numbers called IP addresses, such as a long string of digits separated by dots. Humans are terrible at remembering numbers but good at remembering words. DNS is the system that turns a friendly name into the number a computer actually needs. When you type a website name into your browser, a DNS lookup happens first, and only after the number comes back does the real conversation begin.

Records: The Entries in the Book

Each entry in the DNS phone book is called a record. Different record types answer different questions. An address record says “this name lives at this IP address”. An alias record says “this name is just another name for that other name”. A service record says “this name offers a service on this port”. You will meet all three of these in a Kubernetes cluster, so it helps to keep them in mind.

Resolvers and Servers

Two roles appear in every lookup. The resolver is the small helper built into an application or operating system that asks the question. The DNS server is the machine that knows the answer, or knows who to ask next. In this tutorial, the resolver sits inside every container, and the DNS server is a special component that runs inside the cluster.

Kubernetes is a place where addresses are temporary, so names must be permanent.

Pods Come and Go

A Pod is the smallest running unit in Kubernetes, usually holding one application container. Every Pod receives its own IP address when it starts. But Pods are disposable. They crash, get replaced during updates, move to other machines when a machine fails, and scale up and down as traffic changes. Each replacement Pod gets a brand-new IP address. If one application had to remember the IP address of another Pod, it would break constantly.

Services Give a Stable Front Door

Kubernetes solves part of this with an object called a Service. A Service is a stable virtual address placed in front of a group of Pods. Clients talk to the Service, and Kubernetes quietly forwards their traffic to whichever healthy Pods are currently behind it. The Service address does not change while the Service exists.

That still leaves one small problem. A stable IP address is better than a changing one, but it is still a number. Nobody wants to copy a number into a configuration file and hope it never changes. Kubernetes DNS gives each Service a stable, human-readable name so that applications can simply say “talk to payments” and let the cluster do the rest.

Eight small terms carry almost the entire story of DNS in Kubernetes.

CoreDNS is a small, fast, plug-in based DNS server, and it is the default in modern Kubernetes.

What CoreDNS Does

CoreDNS runs as a normal application inside the cluster, usually as a Deployment with two or more copies in the system namespace. It has two jobs. First, it answers questions about names that belong to the cluster, such as Services and certain Pods. Second, for every other name, such as a public website, it forwards the question to an upstream DNS server outside the cluster and passes the answer back.

How It Knows About the Cluster

CoreDNS does not keep a hand-written list of names. Instead, it watches the Kubernetes API, which is the central brain of the cluster. Whenever a Service or its endpoints are created, changed, or deleted, CoreDNS hears about it almost immediately and updates what it can answer. That is why a brand-new Service becomes resolvable within moments, without any human editing a DNS file.

Where It Sits

flowchart LR
    A["Application Pod"] -->|"1. Where is payments?"| B["kube-dns Service"]
    B --> C["CoreDNS Pod 1"]
    B --> D["CoreDNS Pod 2"]
    C -->|"2. Watches"| E["Kubernetes API"]
    D -->|"2. Watches"| E
    C -->|"3. Unknown names"| F["Upstream DNS"]
    D -->|"3. Unknown names"| F
        

Notice that the application never talks to a CoreDNS Pod directly. It talks to the stable kube-dns Service address, which spreads questions across the available CoreDNS Pods. That means DNS itself enjoys the same stable-address benefit as every other Service.

Every container starts life already knowing where the cluster’s DNS server lives.

The Resolver Configuration File

Inside every Linux container there is a small text file named resolv.conf. It tells the resolver three things: the address of the DNS server to ask, a list of “search domains” to try, and some tuning options. When Kubernetes starts a Pod, the node agent called the kubelet writes this file for the container automatically. The DNS server address it writes is the address of the kube-dns Service.

The Three Things Written Inside

Every Service gets a predictable, fully qualified name built from four parts.

Reading a Full Name

The full name of a Service is written as the Service name, then the namespace, then the word svc, then the cluster domain, all joined by dots. So a Service called payments in a namespace called shop has the full name payments, shop, svc, cluster, local joined with dots. Reading from left to right, it goes from the most specific thing to the most general thing, just like an address that goes from house number to street to city to country.

Short Names That Still Work

You rarely type the full name. If your application Pod is in the same namespace as the Service, the plain word payments is enough. If the Service is in a different namespace, you add the namespace, for example payments dot shop. The search domains in the resolver file fill in the rest automatically. This is a big convenience, because the same configuration can be copied across environments without changing any names.

Different objects produce different kinds of answers, and knowing which is which saves hours of confusion.

This is the most misunderstood corner of Kubernetes DNS, and it explains many mysterious slowdowns.

How Short Names Get Expanded

When your application asks for a name, the resolver has to decide whether the name is already complete or needs a suffix added. The ndots setting is the rule it uses. It means: if the name contains fewer dots than this number, try adding the search domains first, and only afterwards try the name exactly as typed. Kubernetes sets ndots to five by default, which is quite high.

The Hidden Cost for External Names

A public website name typically has only two or three dots, which is fewer than five. So the resolver treats it as “short” and first tries it with each search domain added. Every one of those attempts is a real question sent to CoreDNS, and each returns “no such name” before the correct final attempt succeeds. A single lookup can quietly become four or five.

flowchart TD
    A["App asks for api.example.com"] --> B{"Fewer dots than ndots?"}
    B -->|"Yes"| C["Try with namespace suffix"]
    C --> D["Try with svc suffix"]
    D --> E["Try with cluster suffix"]
    E --> F["Try exact name"]
    F --> G["Answer returned"]
    B -->|"No"| F
        

Some applications need to address individual members, not just “whoever is free”.

Why Individual Names Matter

A database cluster usually has a leader and several followers. The followers must connect to the leader specifically, and every member must know exactly who the others are. Sending traffic to a random Pod would be wrong here. These applications need each member to have a stable, individual name that survives restarts.

How Kubernetes Delivers It

A StatefulSet is a Kubernetes object that runs Pods with stable numbered identities, such as the first, the second, and the third member. When it is paired with a headless Service, each Pod gets its own DNS name made of the Pod name, then the Service name, then the usual namespace and cluster domain. If a Pod is recreated, it returns with the same name, even though its IP address may change, and DNS is updated to the new address.

Let us follow a single question from the moment an application asks it to the moment it gets an answer.

sequenceDiagram
    participant App as Application
    participant Res as Container Resolver
    participant Svc as kube-dns Service
    participant CD as CoreDNS
    participant API as Kubernetes API
    participant Up as Upstream DNS
    App->>Res: Connect to payments
    Res->>Svc: Ask about payments.shop.svc.cluster.local
    Svc->>CD: Forward question to a CoreDNS Pod
    CD->>API: Consults its watched list of Services
    API-->>CD: Service and endpoints data
    CD-->>Res: Answer with the Service address
    Res-->>App: Address ready
    App->>App: Opens connection
    Note over CD,Up: Names outside the cluster go to upstream DNS
        

CoreDNS is built like a row of small workers, each doing exactly one job.

The Corefile

CoreDNS is configured by a single text file called the Corefile. In Kubernetes, this file usually lives inside a ConfigMap, which is a Kubernetes object that stores configuration. The Corefile lists plugins, and every incoming question passes through them in a fixed order. Each plugin can answer the question, change it, or hand it to the next plugin.

Custom Rules Without Chaos

Teams often add extra blocks to the Corefile. A common example is sending all questions for a company-internal domain to the corporate DNS servers, while everything else follows the default path. Because the configuration is a ConfigMap, it can be reviewed, versioned, and rolled back like any other change.

Each Pod can choose its own resolving style, using a setting called dnsPolicy.

Fine-Tuning with Custom DNS Settings

Alongside the policy, a Pod can carry extra DNS configuration: additional name servers, extra search domains, or changed options such as ndots. When the policy is set to None, this becomes the only source of settings. This is the correct, supported way to adjust behaviour for a single workload without touching cluster-wide configuration.

The fastest question is the one that never leaves the machine.

Why Caching Helps

In a busy cluster, thousands of Pods ask for the same handful of names again and again. Answering each one by travelling across the network to a CoreDNS Pod wastes time and adds load. CoreDNS already keeps a short-lived cache, but there is a way to bring the cache even closer to the applications.

The Per-Node Helper

NodeLocal DNSCache is an optional add-on that runs a small DNS caching agent on every node, using a special local address. Pods on that node ask the local agent first. If it already knows the answer, it replies instantly without any network hop. If it does not, it asks the central CoreDNS and remembers the reply. It also talks to CoreDNS over a more reliable connection type, which avoids some rare packet-loss headaches.

flowchart LR
    P1["Pod A"] --> L["Local DNS cache on node"]
    P2["Pod B"] --> L
    L -->|"Cache hit"| P1
    L -->|"Cache miss"| C["Central CoreDNS"]
    C --> L
        

If DNS stops, almost everything else stops with it, so it deserves careful planning.

Why DNS Is a Critical Dependency

Nearly every application call begins with a name lookup. If DNS becomes slow, every request becomes slow. If DNS disappears, applications cannot even find their own databases. That is why DNS is treated as critical infrastructure, more like electricity than like an ordinary app.

Ways to Keep It Healthy

DNS is a quiet doorway, and quiet doorways deserve locks.

Practical Protections

Restrict who may change the DNS configuration through role-based access control. Use network policies, which are Kubernetes firewall rules, to allow DNS traffic only where needed and to limit which workloads can reach external resolvers directly. Watch for unusual bursts of failed or very long lookups. Keep CoreDNS updated so security fixes arrive quickly. Finally, remember that ordinary DNS answers are not signed inside the cluster, so sensitive connections should always be protected with encryption and identity checks at the application layer.

You cannot fix what you cannot see, and DNS problems are famously invisible.

The Signals Worth Watching

CoreDNS publishes metrics that a monitoring system can collect. The most valuable ones tell a simple story about traffic, errors, and speed. Together they answer the questions “how many questions per second?”, “how many are failing?”, and “how long do answers take?”.

Logging with Care

CoreDNS can log every single question, which is priceless when debugging a stubborn problem. But on a busy cluster, that produces a mountain of logs and adds load. Turn it on temporarily, investigate, and turn it off again. For everyday visibility, rely on metrics and on error logs.

Good habits make DNS boring, and boring is exactly what you want.

A short checklist that prevents most DNS trouble before it starts.

When a name will not resolve, walk through the same short path every time.

Here is how DNS quietly powers everyday cluster designs.

Almost always. It is delivered as a standard add-on, and practically every mainstream installation includes it by default. Without it, Service names would not resolve.

For backward compatibility. Many components were already configured to look for that name, so it was kept even after the software behind it changed.

Yes. Add the namespace to the Service name, or use the full name. Namespaces separate things logically, but they do not block DNS lookups by themselves.

Most often because of the ndots setting and search domains, which cause several failed attempts before the right one. A trailing dot or a lower ndots value usually helps.

A normal Service gives one virtual address and spreads traffic for you. A headless Service returns the individual Pod addresses and leaves the choice to the client.

Often yes. The resolver file is created when a Pod starts, so existing Pods keep their old copy. Changes to CoreDNS answers themselves apply without restarting application Pods.

It can be changed when the cluster is created or configured, but it is unusual and needs consistent settings in several places. Most teams keep the default.

At least two, spread across different nodes. Larger clusters should scale the number in proportion to their size and watch the load and latency metrics.

Not in the way a load balancer does. For normal Services, the cluster networking layer spreads the connections. For headless Services, DNS may return several addresses and clients pick one.

It is the standard and by far the most common. Other DNS implementations can be used if they follow the same rules for Kubernetes names, but that is rarely necessary.

Kubernetes is a world where Pods are born, die, and move constantly, so no address can be trusted for long. DNS gives every Service a permanent, readable name, and CoreDNS keeps that phone book perfectly up to date by watching the cluster itself. Each container is told where to ask through an automatically prepared resolver file, search domains let you type short names, and different Service types produce different kinds of answers. With a little care around ndots, caching, redundancy, security, and monitoring, DNS becomes the quiet foundation that lets every other part of the cluster find its friends.