How does a workload running in a Kubernetes cluster resolve another Service by name? Describe what component answers the query and the DNS name forms available.

## Why cluster DNS exists Pod IPs are ephemeral — a rescheduled or scaled workload has different addresses every time — so nothing can be configured with them. A Service supplies a stable virtual address, and DNS supplies a stable *name* for that address. Together they mean an application ships with a hostname in its configuration and never learns anything about placement. ## The component **CoreDNS** is the cluster DNS server: a small plugin-chained DNS server whose `kubernetes` plugin watches Services and EndpointSlices through the API server and answers queries from that live view. It runs as a Deployment (usually two replicas by default) in the `kube-system` namespace, exposed by a Service whose ClusterIP is fixed at cluster creation — conventionally the tenth address of the service CIDR, and conventionally still named `kube-dns` for compatibility with older tooling. The kubelet writes that ClusterIP into every pod's `/etc/resolv.conf` as the `nameserver`. Because the standard C library resolver reads that file, every language's name lookup automatically uses cluster DNS without any library or sidecar. ## The name forms **Services (A/AAAA).** ``` <service>.<namespace>.svc.<cluster-domain> ``` with `cluster.local` as the near-universal cluster domain. For a normal Service this returns exactly one address: the **ClusterIP**. It does not return pod addresses, and it does not load balance — the spread across pods happens after the packet is sent, when the ClusterIP is translated to a backing pod. **Shorter forms.** `/etc/resolv.conf` also carries a `search` list, typically: ``` search <namespace>.svc.cluster.local svc.cluster.local cluster.local ``` The resolver appends each suffix in turn to an unqualified name. So from a pod in `billing`: - `payments` → `payments.billing.svc.cluster.local` (first suffix matches) - `payments.shop` → `payments.shop.svc.cluster.local` (second suffix) - `payments.shop.svc.cluster.local` → resolved as given The common beginner error is expecting a bare name to reach another namespace. It cannot: the first suffix pins it to the caller's own namespace. **Ports (SRV).** ``` _<port-name>._<protocol>.<service>.<namespace>.svc.cluster.local ``` This returns the port number together with the target name, so a client can discover the port rather than hard-coding it — useful when ports are assigned per environment. It requires the Service port to have a `name`. **Pods.** A record of the form `<pod-ip-with-dashes>.<namespace>.pod.cluster.local` resolves to that address. It is rarely used directly by applications; it exists so that constructed names resolve consistently. **ExternalName Services.** `spec.type: ExternalName` with `spec.externalName: db.example.com` creates no ClusterIP and no proxying. The DNS answer is a **CNAME** to the external name, so a workload keeps addressing an in-cluster name while the traffic goes elsewhere. It is a DNS-level indirection only: nothing rewrites TLS SNI or HTTP Host headers, which is why it surprises people with certificate mismatches. **Headless Services.** A Service with `clusterIP: None` has no virtual address, and its name resolves instead to the set of ready backing pod addresses — a different behaviour worth knowing exists, used for peer discovery and client-side load balancing. ## What to verify when a name fails From a debug pod: `cat /etc/resolv.conf` to see the nameserver and search list; `nslookup payments.billing.svc.cluster.local`; then compare with `kubectl get svc -n billing payments`. Three failures dominate: the Service does not exist in the namespace you assumed; the name was left unqualified and hit the caller's namespace instead; or the Service exists but has no ready endpoints, in which case the ClusterIP still resolves and connections fail afterwards — which is an important distinction, because a successful lookup does not imply a working backend. ## The mental model to carry DNS in Kubernetes answers "what address", never "which pod is healthy". Health and distribution are the Service's job. A name resolving correctly while requests fail is normal and points downstream, not at DNS.