Egress filtering falls back to a hardcoded 8.8.8.8, and UPSTREAM_DNS cannot override it

[dvystrcil]

Description

When egress filtering is enabled, entrypoint.sh falls back to Google's public resolver (8.8.8.8) for the dnsmasq upstream, and there is no supported way for an operator to choose a different one.

https://github.com/open-webui/open-terminal/blob/main/entrypoint.sh#L116-L118

# Capture the current upstream nameserver before we override resolv.conf
UPSTREAM_DNS=$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')
UPSTREAM_DNS="${UPSTREAM_DNS:-8.8.8.8}"

Two small things follow from this:

1. The fallback is a hardcoded third-party resolver. For an egress-filtering feature in a self-hosted tool, silently sending DNS to Google when detection fails is a policy decision the operator may not expect. It is not mentioned in the README, so there is nothing to discover before it happens.

2. It cannot be overridden. Line 117 assigns unconditionally, so an exported UPSTREAM_DNS is discarded before the :- default on line 118 is consulted. The ${UPSTREAM_DNS:-…} form reads like an override hook, but setting it has no effect.

Impact

Low, and situational rather than a crash. In Kubernetes and most Docker setups /etc/resolv.conf always carries a nameserver, so the fallback rarely fires — I confirmed it never fires in our deployment. It matters for anyone who wants to pin the resolver (corporate split-DNS, Pi-hole, an internal-only network, or simply a preference not to use Google), because today there is no way to express that.

Suggested fix

A one-line reordering makes the variable behave the way its :- form suggests, and lets the fallback stay as-is:

UPSTREAM_DNS="${UPSTREAM_DNS:-$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')}"
UPSTREAM_DNS="${UPSTREAM_DNS:-8.8.8.8}"

An explicitly set value wins; otherwise detection; otherwise the existing default. No behaviour change for anyone not setting it.

I have deliberately not assumed which default you would want — whether the fallback should stay 8.8.8.8, become a documented option, or fail loudly instead, is your call and I would rather hear your take than presume.

Prior art

I searched open and closed issues and PRs and did not find this specific point — apologies if I missed one. #119 / #118 cover the same entrypoint.sh egress path but different faults (capsh privileges, and iptables blocking dnsmasq's own upstream queries), so this looked distinct rather than a duplicate.

Environment

• entrypoint.sh and entrypoint-slim.sh on main at the time of writing
• Found while auditing our homelab for non-Cloudflare resolvers; we run a fork and have applied a local change, so nothing is blocked on this

Offer

Happy to open a PR with the reordering above, or with whatever shape you prefer — just say which and I will follow it. Equally happy for you to close this if the current behaviour is intentional.

Thanks for the project.