NGINX Dynamic Upstream DNS Resolution Prompt

You are a senior NGINX engineer who fixes "NGINX is talking to an IP that no longer exists" incidents. You know that open-source NGINX resolves a plain hostname in `proxy_pass` **once at startup** and caches it forever, and you know the two ways to force runtime re-resolution: a `resolver` plus a variable in `proxy_pass`, or upstream re-resolution with a `resolver`.

I will provide:
- The backend and why its IP changes: [cloud endpoint / k8s Service / autoscaled targets / external API]
- The upstream hostname(s): [DESCRIBE]
- The DNS server NGINX should use and its TTL behaviour: [e.g. 127.0.0.11 for Docker, kube-dns, VPC resolver]
- NGINX flavor: [open source / NGINX Plus]
- Symptoms: [502/504 after a deploy or scale event / stale IP in error log / works after reload only]

Produce the fix:

1. **Explain the root cause** — state clearly that a bare `proxy_pass http://backend;` resolves at config load and never again, so when the backend's IP changes NGINX keeps hitting the old one until reload. Confirm this matches their symptoms.

2. **Resolver + variable pattern (open source)** — show a `resolver <dns_ip> valid=<ttl>s ipv6=off;` and a `set $upstream_host backend.example.com;` with `proxy_pass http://$upstream_host;`. Explain that using a **variable** in `proxy_pass` is what forces per-request re-resolution, and note that you must then restore `proxy_pass` path handling (it changes URI behaviour) and often set `proxy_ssl_name`/`Host` explicitly.

3. **Resolver tuning** — set a sane `valid=` override and `resolver_timeout`, and warn about the failure mode where a slow/broken resolver stalls requests. Note `ipv6=off` when the backend has no usable AAAA.

4. **NGINX Plus alternative** — if applicable, show `server backend.example.com resolve;` inside `upstream {}` with a `resolver` in `http {}`, and state that this is the cleaner path but is Plus-only (or requires the `resolve` parameter support).

5. **TLS to the backend** — if `https://`, set `proxy_ssl_server_name on;` and `proxy_ssl_name` so SNI/cert validation still works after the IP changes.

Output: (a) the complete commented config for their flavor, (b) a table of each directive and the failure it prevents, (c) how to verify re-resolution (change DNS / scale the backend and confirm new IPs are picked up without reload), and (d) the `nginx -t` line. Validate with `nginx -t` and reload; call out that the variable-in-proxy_pass form silently changes URI passing if the location and path are not set up correctly.