Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#4154 - procd-ujail: makes dnsmasq refuse to answer dns queries #9139

Open
openwrt-bot opened this issue Nov 24, 2021 · 2 comments
Open

FS#4154 - procd-ujail: makes dnsmasq refuse to answer dns queries #9139

openwrt-bot opened this issue Nov 24, 2021 · 2 comments
Labels

Comments

@openwrt-bot
Copy link

wwortel:

22/11/2021 compile for ramips device Ubiquiti EdgeRouter X sfp ; snapshot: r18166-e2c4998f6d
Choosing TARGET_ramips_mt7621_DEVICE_ubnt_edgerouter-x-sfp selects default the inclusion of procd-ujail .
This has the effect of dnsmasq being put in a jail.
The device can still make dns queries to upstream. But, depite dnsmasq listening on all interfaces, any incoming queries get the reply 'REFUSED'. Easily tested on the device itself e.g. with the command 'nslookup localhost'
This leaves any devices downstream in the dark that via dhcp got the news to fetch their dns information from this jailed dnsmasq.
Exactly same configuration compile, but with procd-ujail manually removed, restores complete functionality of dnsmasq.

@openwrt-bot
Copy link
Author

wwortel:

additional info:
comparing in logread what is shown upon start of dnsmasq there is the difference :
with proc-ujail
dnsmasq[10121]: UBus support enabled: connected to system bus
dnsmasq[10121]: using only locally-known addresses for test
dnsmasq[10121]: using only locally-known addresses for onion
dnsmasq[10121]: using only locally-known addresses for localhost
dnsmasq[10121]: using only locally-known addresses for local
dnsmasq[10121]: using only locally-known addresses for invalid
dnsmasq[10121]: using only locally-known addresses for bind
dnsmasq[10121]: using only locally-known addresses for lan
dnsmasq[10121]: read /etc/hosts - 4 addresses
dnsmasq[10121]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses

withhout procd-ujail:
dnsmasq[10121]: UBus support enabled: connected to system bus
dnsmasq[10121]: using only locally-known addresses for test
dnsmasq[10121]: using only locally-known addresses for onion
dnsmasq[10121]: using only locally-known addresses for localhost
dnsmasq[10121]: using only locally-known addresses for local
dnsmasq[10121]: using only locally-known addresses for invalid
dnsmasq[10121]: using only locally-known addresses for bind
dnsmasq[10121]: using only locally-known addresses for lan
dnsmasq[10121]: reading /tmp/resolv.conf.d/resolv.conf.auto
dnsmasq[10121]: using nameserver 192.168.1.1#53
dnsmasq[10121]: using only locally-known addresses for test
dnsmasq[10121]: using only locally-known addresses for onion
dnsmasq[10121]: using only locally-known addresses for localhost
dnsmasq[10121]: using only locally-known addresses for local
dnsmasq[10121]: using only locally-known addresses for invalid
dnsmasq[10121]: using only locally-known addresses for bind
dnsmasq[10121]: using only locally-known addresses for lan
dnsmasq[10121]: read /etc/hosts - 4 addresses
dnsmasq[10121]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses

In both cases the unit does reach itself fqdn ddresses on the internet.
The jailed version however serves requests it receives with 'REFUSED'.

@discordianfish
Copy link

Just happened to me on a fresh OpenWrt 23.05.0-rc3 install on x86/64:

NAME="OpenWrt"
VERSION="23.05.0-rc3"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt 23.05.0-rc3"
VERSION_ID="23.05.0-rc3"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r23389-5deed175a5"
OPENWRT_BOARD="x86/64"
OPENWRT_ARCH="x86_64"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"

And as observed above, commenting out the procd_add_jail lines in the init file seems to fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants