An Envoy cluster with type: LOGICAL_DNS points at a DNS name that resolves to many backend addresses, yet almost all traffic lands on one backend. What does LOGICAL_DNS do that STRICT_DNS does not, and which would you use here?

## The cluster type field A cluster answers one question: which endpoints are in this upstream group and how do we learn about them? The `type` field names the mechanism: - **`STATIC`** — endpoints are literal IP:port pairs in `load_assignment`. No resolution at all. - **`STRICT_DNS`** — a hostname is resolved on a timer and *all* returned addresses become hosts. - **`LOGICAL_DNS`** — a hostname is resolved, but the cluster holds a single logical host. - **`EDS`** — endpoints are delivered dynamically by a management server. - **`ORIGINAL_DST`** — the destination comes from the connection's original destination address, for transparent proxying. Everything else about the cluster — `lb_policy`, `connect_timeout`, upstream TLS, protocol options — is orthogonal to the type. But the type decides how many things the load balancer has to choose between, which is why it can quietly nullify your load-balancing configuration. ## STRICT_DNS in detail Envoy asynchronously resolves the configured name at `dns_refresh_rate` (five seconds by default), or according to the record TTL if `respect_dns_ttl` is enabled. Every address in the answer becomes a distinct host in the cluster, with its own connection pool and its own health status. Hosts that disappear from a later answer are removed; new ones are added. Two names that resolve to the same address still produce two hosts, because identity is per resolved entry. This is what you want when the name genuinely represents a set of interchangeable backends: `LEAST_REQUEST` or `ROUND_ROBIN` then has real choices, an unhealthy backend can be ejected individually, and connection pools are per host. ## LOGICAL_DNS in detail LOGICAL_DNS was built for a different problem: talking to a huge external service whose name resolves to a large, rapidly rotating address set. Materialising every address would mean a big host table churning constantly, for no benefit — the client just needs *a* working connection to *the* service. So the cluster keeps one logical host. Resolution still happens in the background, and the address used for **new** connections is refreshed, but existing connections are not torn down when the answer changes. The load balancer sees one host, so `lb_policy` is effectively inert. ## Why your traffic pinned to one backend Put those together with connection reuse and the symptom is inevitable: - Only one endpoint exists, so every request goes to whatever address that logical host currently holds. - With HTTP/2 to the upstream, one connection carries many concurrent streams, so even long-lived load stays on the single connection to that one address. - With HTTP/1.1 and keep-alive, the pool's connections were all established against the address that was current when they were created. Nothing is broken; the cluster is doing precisely what LOGICAL_DNS promises. The mismatch is between the type and the intent. ```yaml clusters: - name: service_backend connect_timeout: 0.25s type: STRICT_DNS # every resolved address becomes a host lb_policy: LEAST_REQUEST load_assignment: cluster_name: service_backend endpoints: - lb_endpoints: - endpoint: address: socket_address: { address: backend.internal, port_value: 8080 } ``` ## Choosing between them - **Internal service names resolving to your own fleet** → `STRICT_DNS`, so balancing and per-endpoint health work. - **Large external endpoints with volatile address sets** → `LOGICAL_DNS`, to avoid a churning host table. - **You run a control plane that knows the real membership** → `EDS`, which removes DNS from the path entirely and gives you locality and per-endpoint metadata. - **A fixed, known set** → `STATIC`. ## Related sharp edges `dns_lookup_family` controls whether Envoy uses A records, AAAA records, or both — a cluster set to one family against a name that only publishes the other resolves to nothing and every request fails, which looks like an outage rather than a config error. And with `STRICT_DNS`, a name resolving to a very large answer set produces a correspondingly large host table, so a low refresh rate against a big set costs real CPU. Whatever the type, remember DNS answers are cached by Envoy on its own schedule, so a backend rotation is visible only as fast as the refresh interval allows. ## How to confirm it in production The direct check is the cluster's membership: how many hosts does the cluster actually have? One host in a cluster you believed was balancing over ten is the whole answer, and it points straight at the type field rather than at the load-balancing policy you were about to start tuning.