For the scenario of a dumb Wi-Fi access point, the Wiki explains how to disable the service dnsmasq completely. Because that also disables the local DNS proxy, I propose to remove that alternative path. In other words: Just document that other alternative
uci set dhcp.lan.ignore=1 and do not show how to disable
dnsmasq completely as service has the side-effect that there is no local DNS proxy running anymore either. Consequently, OpenWrt local services which require DNS, like the OpenWrt update/package manager
opgk do not work anymore then (at least according my tests).
dnsmasq is not disabled, its DNS proxy is still listening on udp/53 and tcp/53 on all IP addresses. This includes even those IP addresses globally reachable: Anyhost. Therefore, I propose to note as well that the DNS proxy has to be limited to Localhost.
On the Internet, services exist, which allow to surf Internet not via HTTP but DNS. Those proxy services were invented to circumvent captive portals or content filters. When I use my OpenWrt as LAN client, in a hotel for example, and I am not isolated from others, an attacker could use my public DNS proxy to surf and cloak his behavior. Deeper investigation later would identify me as culprit (my OpenWrt device) rather than the attacker. In other words: A device should only offer those services which are required or have a reason. I do not see any reason for a LAN client to offer a DNS proxy on default. The current state can be seen by going for
netstat -tulpen on the OpenWrt device, or by sending DNS queries from another device (attacker) to the OpenWrt device (me) via those IP addresses visible in the tool
ifconfig, for example
dig +short @<ip-address-of-OpenWrt> forum.openwrt.org.
dnsmasq has to listen to Localhost but not to Anyhost. I do not know how the OpenWrt community documents things like this second proposal. To achieve that proposal, I had to edit the file
/etc/dnsmasq.conf and add the line
listen-address=::1,127.0.0.1. I found no way via an UCI option. I even searched the source code, and found no alternative to the command-line parameter ‘listen-address’.
There are a lot of other use cases around Open DNS Resolvers. However, in case of of OpenWrt used as dumb Wi-Fi access point in an untrusted environment, I am more about that bad-content-surfing aka ‘DNS tunneling’ explained above. In any case, a documentation in the OpenWrt Wiki should not show the user how to create Open DNS Resolver as side effect.