🐛DNS resolver refresh logic enters a failure state that persists until the pod is restarted.

**Describe the bug**

We experienced a transient connectivity issue to the CoreDNS service in one of our K8s clusters that coincided with a cloudflared pod entering its DNS resolver refresh logic.

This resulted in a traffic outage for requests routed through that connector (502 errors)

From the Cloudflare Zero Trust dashboard, the tunnel remained in a “working” state for the entire duration of the outage, despite traffic failures.

The error log below occurred every 5 minutes.

Failing traffic and the cloudflared errors stopped only after restarting the pod.

To mitigate this type of issue in the future, I've tried to use the --dns-resolver-addrs flag to configure a static DNS resolver (i.e., set to the CoreDNS service CLUSTER_IP value) to disable resolver refresh behavior.

Based on this commit:

> commit 398da8860f39617a2bb112f59ed3498af6a704ae
> Date: Mon Jun 30 15:20:32 2025 -0700
>
> TUN-9473: Add --dns-resolver-addrs flag
>
> To help support users with environments that don't work well with the
> DNS local resolver's automatic resolution process for local resolver
> addresses, we introduce a flag to provide them statically to the
> runtime. When providing the resolver addresses, cloudflared will no
> longer lookup the DNS resolver addresses and use the user input
> directly.
>
> When provided with a list of DNS resolvers larger than one, the resolver
> service will randomly select one at random for each incoming request.
>
> Closes TUN-9473

However, the flag is rejected as undefined when used with `cloudflared tunnel run`, even though the commit suggests it should be available to disable resolver refresh behavior.

The error is "`Incorrect Usage. flag provided but not defined: --dns-resolver-addrs`"

The flag is also not listed in `cloudflared tunnel run --help`.

**To Reproduce**
Steps to reproduce the behavior:
1. Configure --dns-resolver-addrs flag by adding to cloudflared container arg

```
args:
- tunnel
- --dns-resolver-addrs=
- --config
- /etc/cloudflared/config/config.yaml
- run
```

**Expected behavior**

Is `--dns-resolver-addrs` intended to be supported for `cloudflared tunnel run`, or is there an alternative supported mechanism to enable static DNS resolver behavior for tunnels ?

In Kubernetes clusters, the CoreDNS ClusterIP is stable for the lifetime of the Service, so dynamic resolver refresh every 5 minutes is unnecessary and can introduce persistent failure states.

**Environment and versions**
- Architecture: Kubernetes
- Version: 2025.11.1

**Logs and errors**

>
2025-12-13T00:54:05Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T00:59:10Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:04:15Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:09:20Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:14:25Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:19:30Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:24:35Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:29:40Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:34:45Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:44:50Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T01:55:00Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T02:00:05Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"
2025-12-13T02:10:10Z ERR Failed to refresh DNS local resolver error="lookup region1.v2.argotunnel.com: i/o timeout"

**Additional context**
None