# Plan the client for a Kubernetes headless Service address set > Distinguish a normal Service’s cluster-IP answer from a headless Service’s selected-Pod address set. Review named-port SRV answers with the client that will consume them. - Canonical URL: https://update.dsesecurity.com/updates/plan-the-client-for-a-kubernetes-headless-service-address-set/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T20:32:50+00:00 - Modified: 2026-10-29T20:33:35+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Distinguish a normal Service’s cluster-IP answer from a headless Service’s selected-Pod address set. Review named-port SRV answers with the client that will consume them. ## Potentially affected Kubernetes workloads using the documented DNS records for ordinary or headless Services and named service ports; confirm actual DNS and client support. ## DSE recommendation DSE recommends accepting the client’s intended Service answer-set handling before adopting a headless discovery design. ## Article Bottom line: Decide what the client will do with a set of endpoints before adopting headless discovery. Keep the Service definition, returned records and client behavior together instead of assuming that a familiar DNS name always represents one virtual address. ## Source fact: documented behavior The [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) documentation is the primary reference. A normal Service has A or AAAA records resolving to its cluster IP, while the documented headless Service name resolves to a set of selected Pod IPs. The headless-Service guidance expects clients to consume that set or use standard round-robin selection from it. SRV records are created for named service ports; a regular Service returns its service domain and port, whereas a headless Service returns per-Pod domain-and-port answers. ## What the source does not establish This article concerns the documented Service record shapes and the consuming client. It does not specify an application membership protocol, endorse undocumented DNS layouts or turn name resolution into a connectivity guarantee. Keep readiness publication, caching, retries, TLS identity and generic SRV priority/weight behavior within their own exact requirements. Short-name troubleshooting is covered separately from this discovery-design decision. ## Applicability questions - Is the Service ordinary or deliberately headless? - Which address or named-port record does the client request? - Can the intended client consume the actual answer set? - How will application-level endpoint acceptance be observed independently? ## DSE recommendation: review discovery from the consumer outward DSE recommends accepting the client’s intended Service answer-set handling before adopting a headless discovery design. Start with the application’s documented discovery requirement and actual client implementation. Record the Service namespace, selectors, relevant port names and desired endpoint population. Have the application owner distinguish discovering individual members from reaching a service through its ordinary cluster address. Do not choose headless behavior solely because a DNS name resolves in an administrative shell. Write the expected record shape beside the exact query. For address lookup, identify whether the design expects a virtual address or a member set. For named-port discovery, preserve both target and port in the planning record. Keep the record’s structural meaning separate from any algorithm the client uses to select, retain or replace a member. Inspect the actual approved response from the intended workload context. Compare all relevant answers with the expected endpoint population and the client configuration. Preserve missing, additional or differently named entries as investigation evidence. Avoid changing shared DNS infrastructure merely to force a response into the one-address shape expected by an unsuitable client. Have the application owner approve the subsequent connection and recovery tests. Keep any membership, authentication or stateful-service requirements with that application procedure. A DNS response can inform the next step without closing those independent acceptance questions. ## Verification and evidence Proposed verification, not performed: prepare two disposable Services over harmless test workloads, one ordinary and one headless, with an approved named port. Predict the address and SRV answer shapes before querying them from the test client context. Capture the actual complete answers, compare them with the Service and selected workloads, and exercise the client’s documented handling of the intended set. Use a separate authorized membership-change case only if the application procedure defines it. Retain query names, Service revision, answers and client observations without attributing an unperformed failover or connection result to successful DNS resolution. ## Official references - [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — DNS for Services and Pods - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the client for a Kubernetes headless Service address set,” DSE Security, https://update.dsesecurity.com/updates/plan-the-client-for-a-kubernetes-headless-service-address-set/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.