Cross-namespace Service DNS resolution

WHAT THIS TESTS Understanding cluster DNS, which is how Pods find Services by name instead of IP, and the critical role of namespace scoping.

A GOOD ANSWER COVERS Kubernetes runs a cluster DNS service, typically CoreDNS. For every Service it creates an A (or AAAA) record following the form service-name.namespace.svc.cluster.local. A Pod's resolv.conf includes search domains for its own namespace, so within the same namespace a Pod can use just the Service's short name. To reach a Service in a different namespace, you must include the namespace: the minimal form is my-service.B, and the fully qualified domain name is my-service.B.svc.cluster.local. Using only my-service from namespace A resolves against A's search path and will not find the Service in B.

COMMON WRONG ANSWERS Using the bare Service name across namespaces. Getting the segment order wrong, such as namespace before service. Forgetting the svc and cluster.local parts of the FQDN.

LIKELY FOLLOW-UPS What provides the search domains? The Pod's DNS config injected by the kubelet. How are headless Services resolved? They return individual Pod A records rather than a single ClusterIP. What is the SRV record form? Includes port and protocol for named ports.

ONE CONCRETE EXAMPLE An app Pod in namespace A needs the payments Service in namespace B. It connects to my-service.B.svc.cluster.local (or simply my-service.B). CoreDNS returns the ClusterIP of that Service, and traffic is load-balanced to B's Pods. Had the app used just my-service, DNS would have searched namespace A and returned no answer.