mirror of
https://github.com/open-webui/open-terminal.git
synced 2026-11-05 01:27:28 +00:00
[GH-ISSUE #155] Egress filtering falls back to a hardcoded 8.8.8.8, and UPSTREAM_DNS cannot override it #91
Labels
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
open-webui/open-terminal#91
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dvystrcil on GitHub (Aug 16, 2026).
Original GitHub issue: https://github.com/open-webui/open-terminal/issues/155
Description
When egress filtering is enabled,
entrypoint.shfalls 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
Two small things follow from this:
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.
It cannot be overridden. Line 117 assigns unconditionally, so an exported
UPSTREAM_DNSis 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.confalways 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: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.shegress path but different faults (capshprivileges, and iptables blocking dnsmasq's own upstream queries), so this looked distinct rather than a duplicate.Environment
entrypoint.shandentrypoint-slim.shonmainat the time of writingOffer
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.
@maurerle commented on GitHub (Aug 23, 2026):
Would be good to have a fix for this.
I'd go with: