Skip to main content

DNS and namespaces

Stage 2 · Guidance

The booking service calls http://flight:8081/api/flights. The name flight is not a public internet domain; it is an internal hostname resolved by CoreDNS, Kubernetes' in-cluster DNS server.

CoreDNS expands short hostnames using the caller's namespace context. When services move into separate namespaces, understanding DNS search domains becomes essential to prevent connection failures.

How CoreDNS search domains expand short names​

The kubelet populates /etc/resolv.conf inside every container upon boot. For a Pod running in apollo-airlines-apps:

search apollo-airlines-apps.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.96.0.10
options ndots:5

When booking queries flight, the resolver checks each domain in the search path sequentially:

  • Step 1: Appends apollo-airlines-apps.svc.cluster.local.
  • Step 2: Resolves to the Service ClusterIP (10.96.140.22).
  • Step 3: Returns the virtual IP without needing full qualification.

Diagram NW-04 — short name resolution uses the caller's namespace search domain; packets target the ClusterIP.

Why cross-namespace calls fail without qualification​

When a client in apollo-airlines-ui attempts to call http://identity:8080:

  • The resolver queries identity.apollo-airlines-ui.svc.cluster.local.
  • No such Service exists in that namespace.
  • Resolution fails with NXDOMAIN.

To communicate across namespaces, qualify the service name:

Name formatResolution pathWhere it works
identityidentity.<caller-ns>.svc.cluster.localSame namespace only
identity.apollo-airlines-appsidentity.apollo-airlines-apps.svc.cluster.localAcross any namespace in the cluster
identity.apollo-airlines-apps.svc.cluster.localExact FQDNEverywhere, without search query overhead

Best practice: In shared ConfigMaps, always declare service URLs using at least namespace qualification (http://identity.apollo-airlines-apps:8080).

Beyond DNS: what namespaces isolate​

Namespaces represent logical organizational boundaries, scoping:

  • 1. DNS search scopes: Isolating default hostname lookups.
  • 2. RBAC permissions: Restricting developer and service access to specific environments.
  • 3. NetworkPolicies: Applying firewall and ingress rules to targeted groups of Pods.
  • 4. ResourceQuotas & LimitRanges: Constraining aggregate memory and CPU consumption.

Evidence and limits​

A successful DNS query only proves name-to-IP resolution. It does not prove application health:

  • 1. Inspect Pod resolver configuration: 
    kubectl exec -n apollo-airlines-apps deploy/booking -- cat /etc/resolv.conf
  • 2. Test same-namespace lookup: 
    kubectl exec -n apollo-airlines-apps deploy/booking -- nslookup flight
  • 3. Test cross-namespace lookup: 
    kubectl exec -n apollo-airlines-ui curl-client -- nslookup identity.apollo-airlines-apps
  • 4. Inspect endpoints: If DNS succeeds but calls timeout, check whether the Service has active endpoints: 
    kubectl get endpoints flight -n apollo-airlines-apps