Problem
In network-isolation mode, AWF detects the DNS resolver configured on the self-hosted runner, then discards it and silently substitutes Google Public DNS.
Our runner uses an organisation-provided resolver, which AWF detects correctly:
Auto-detected DNS servers from /run/systemd/resolve/resolv.conf: [CORPORATE_DNS_IP]
AWF then replaces it:
Network-isolation: removing 1 non-portable DNS server(s) ...
Network-isolation: no portable DNS servers remain after filtering; falling back to 8.8.8.8, 8.8.4.4.
Our corporate network intentionally blocks external DNS. Consequently, the AWF Squid container cannot resolve allowed public endpoints, and outbound Copilot calls fail:
CONNECT 503 TCP_TUNNEL:HIER_NONE
Why this is a bug
The runner’s DNS configuration is an operator-controlled network setting. Replacing it with unrelated public DNS servers breaks normal enterprise environments, where public DNS is commonly blocked for security and compliance.
This is particularly problematic on cloud runners, where provider or organisation DNS resolvers can be virtual-network-specific and may be the only permitted resolvers. A resolver not being globally routable does not make it invalid or unavailable to containers on that runner.
Expected behaviour
When no DNS override is explicitly configured, AWF should preserve and use the DNS resolver detected from the runner, including in Squid’s dns_nameservers configuration.
If AWF believes the detected resolver may be unreachable from its Docker topology, it should test reachability from the relevant container and report a clear, actionable failure if it is unavailable. It should not silently replace the configured resolver with Google Public DNS.
An explicit DNS override remains useful for exceptional cases, but should not be required merely to retain the DNS resolver assigned to the host.
Environment
- AWF: v0.27.44
gh-aw: v0.86.2- Runner: self-hosted cloud VM
- AWF network isolation: enabled
- Public DNS: intentionally blocked by corporate network policy
Current workaround
Disable AWF entirely, or intercept/DNAT requests to 8.8.8.8 and 8.8.4.4 to an internal resolver. Neither is desirable: the former removes the AWF security boundary and the latter is network-specific plumbing that masks the framework behaviour.
Related
This produces the same Squid symptom as #6704 (503 TCP_TUNNEL:HIER_NONE) but has a different root cause. #6704 concerns Tailscale policy routing capturing AWF bridge egress; this issue occurs without Tailscale because AWF replaces the host-assigned resolver with unavailable public resolvers.
Problem
In network-isolation mode, AWF detects the DNS resolver configured on the self-hosted runner, then discards it and silently substitutes Google Public DNS.
Our runner uses an organisation-provided resolver, which AWF detects correctly:
AWF then replaces it:
Our corporate network intentionally blocks external DNS. Consequently, the AWF Squid container cannot resolve allowed public endpoints, and outbound Copilot calls fail:
Why this is a bug
The runner’s DNS configuration is an operator-controlled network setting. Replacing it with unrelated public DNS servers breaks normal enterprise environments, where public DNS is commonly blocked for security and compliance.
This is particularly problematic on cloud runners, where provider or organisation DNS resolvers can be virtual-network-specific and may be the only permitted resolvers. A resolver not being globally routable does not make it invalid or unavailable to containers on that runner.
Expected behaviour
When no DNS override is explicitly configured, AWF should preserve and use the DNS resolver detected from the runner, including in Squid’s
dns_nameserversconfiguration.If AWF believes the detected resolver may be unreachable from its Docker topology, it should test reachability from the relevant container and report a clear, actionable failure if it is unavailable. It should not silently replace the configured resolver with Google Public DNS.
An explicit DNS override remains useful for exceptional cases, but should not be required merely to retain the DNS resolver assigned to the host.
Environment
gh-aw: v0.86.2Current workaround
Disable AWF entirely, or intercept/DNAT requests to
8.8.8.8and8.8.4.4to an internal resolver. Neither is desirable: the former removes the AWF security boundary and the latter is network-specific plumbing that masks the framework behaviour.Related
This produces the same Squid symptom as #6704 (
503 TCP_TUNNEL:HIER_NONE) but has a different root cause. #6704 concerns Tailscale policy routing capturing AWF bridge egress; this issue occurs without Tailscale because AWF replaces the host-assigned resolver with unavailable public resolvers.