In a Helm chart, why does `getHostByName` render an empty string?

### The symptom A chart for a chat fan-out service wants to pin an upstream broker's address at install time, so a template does something like `brokerAddress: {{ getHostByName .Values.broker.host }}`. It renders, nothing errors, and the field comes out empty. The pod starts and dials nothing. Nothing in the output says why. ### The mechanism `getHostByName` is a sprig function that performs a DNS A-record lookup. Helm registers it, but it treats DNS resolution during a render as an opt-in capability: unless the rendering command is given `--enable-dns`, the lookup does not happen and the function returns an empty string. It does not raise an error, which is exactly why this costs someone an afternoon — an empty string flows through the pipeline and lands in the manifest as a blank value, or disappears entirely if it was piped into something that treats empty as absent. So the first fork in diagnosis is: was `--enable-dns` passed to whatever produced this manifest? A blank result is far more likely to mean "resolution is off" than "the name does not exist". ### Why it is off by default A render that performs network I/O stops being reproducible. Helm's rendering model is that a chart plus its values produce a manifest; the whole value of `helm template` in review, of comparing two renders, and of trusting that what you inspected is what gets applied, rests on the render being a pure function of its inputs. A DNS lookup makes the output depend on the resolver, the network and the moment. It also makes rendering fail in an air-gapped or egress-restricted environment for reasons that have nothing to do with the chart. ### Why enabling it rarely fixes the design Even with `--enable-dns`, three things remain true and each one is the actual interview point: 1. **The lookup runs on the rendering host.** Helm renders client-side. The resolver used is the one belonging to the machine running the command — a laptop, a CI runner, an agent. It is not the cluster's DNS, and it is not the resolver the pod will use. A Service name that resolves perfectly inside the cluster will not resolve on a build agent at all. 2. **The result depends on where you rendered.** An external name behind geo-aware DNS answers differently in different regions. Render the same chart and values on a runner in one region and on one in another and you get two manifests that differ in a field neither chart nor values mentions. Every subsequent diff of the release's stored manifest against a fresh render shows drift that is not drift. 3. **The address is frozen.** Whatever was resolved is baked into the rendered manifest and into the manifest stored with that revision. When the upstream address changes, the release does not notice; it keeps the value it captured, until someone happens to run an upgrade, at which point it silently captures a new one. ### What to do instead Resolve at runtime, where resolution belongs. A pod resolving a name through the cluster's DNS gets the current answer, follows changes, and behaves identically no matter who installed the chart. If the address must be decided outside the cluster — an external broker chosen per environment — make it a value, so it is explicit, reviewable, recorded with the release and visible in `helm get values`. If a chart you did not write depends on `getHostByName`, treat that as a portability defect worth patching rather than a flag to turn on globally in your pipeline. ### Where it legitimately appears There is a narrow case: a template that needs a literal IP address, for a field that will not accept a name, in an environment where the rendering host and the cluster share the same resolver view and the address is genuinely stable. That is a real situation, and it is why the capability exists at all. It is worth knowing the flag and the empty-string behaviour, but nobody's offer turns on it — the reason to know it is that the empty string gives no clue whatsoever when you meet it in someone else's chart.