[GH-ISSUE #155] Egress filtering falls back to a hardcoded 8.8.8.8, and UPSTREAM_DNS cannot override it #91

Open
opened 2026-10-18 21:10:39 +00:00 by bsakaguchi · 1 comment
Owner

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.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.

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.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 ```sh # 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: ```sh 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.
Author
Owner

@maurerle commented on GitHub (Aug 23, 2026):

Would be good to have a fix for this.
I'd go with:

UPSTREAM_DNS="${UPSTREAM_DNS:-$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')}"
UPSTREAM_DNS="${UPSTREAM_DNS:-8.8.8.8}"
<!-- gh-comment-id:5385638155 --> @maurerle commented on GitHub (Aug 23, 2026): Would be good to have a fix for this. I'd go with: ``` UPSTREAM_DNS="${UPSTREAM_DNS:-$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')}" UPSTREAM_DNS="${UPSTREAM_DNS:-8.8.8.8}" ```
Sign in to join this conversation.
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
open-webui/open-terminal#91
No description provided.