Proposal 1:
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.
Rationale 1:
Disabling 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).
Proposal 2:
When 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.
Rationale 2:
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.
My problem: 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’.
Security:
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.
I don't mean to be scathing in any way but you seem to have numerous misconceptions about what a wireless access point is and what it should be used for.
If you are wanting a device to give you a secure connection to a public wifi then you should be using a travel ROUTER to securely firewall yourself from the public network. The public network will then only see your travel router and nothing of your phone, tablet, laptop etc.
In my opinion the "Dumb AP" wiki page should be deleted and replaced with something that clearly describes what a wireless access point is and what it is used for followed by an updated guide showing how to configure it.
The existing wiki entry is very confusing for the uninitiated that are trying to learn.
To say it short and easy, I disagree. You are a firewall guy. I am a service guy. The problem in my case is much more different: I am using an Internet service (in hotels) which does not allow/support double NAT scenarios. And I am not allowed to create a VPN (because of legal reasons). Therefore, I need ‘not insecure’ active network equipment; and a dumb Wi-Fi access point in my travel bag. The existing Wiki entry is good. I do not need a hardened device/network. But I definitely do not need an insecure device.
From another Wiki page, the disabling DNS role section did the trick. I have yet to understand what ‘localuse=0’ does under the hood.
Well yes, clearly not a networks service guy. Even if a hotel knew what NAT was, there is no way to detect NAT if you were using it.
A wireless access point is a transparent layer 2 bridge between its own wifi interface that clients can connect to and some other upstream network.
It does not even need IP support unless you want online admin. A DNS server or proxy running on it has no use whatsoever (as it does not need IP to be a wireless access point).
Exactly – that is what this thread is about. A Wi-Fi access point shall not offer a public DNS resolver. If the DNS resolver is disabled, it must be done correctly, so the automatic software updater on the Wi-Fi access points still works. That is not done right now with the above Wiki.
I am about not introducing another NAT. The Wi-Fi client I am using behind my OpenWrt does not cope with double-NAT scenarios. Therefore, I need not a router but an access point.
@vgaetera@yousong perhaps you can recommend what to use on a Dumb AP:
a) local DNS resolver limited to localhost, as explained in my initial post; or
b) DNS done externally, as introduced by uci set dhcp.@dnsmasq[0].localuse='0'
The current Wiki explanation either creates either an Open DNS Resolver or kills DNS resolution completely, even for internal tools, apps, and services.
Well, it works for me no matter if dnsmasq is enabled/running or disabled/stopped.
You probably encountered some sort of race condition related to options noresolv or localuse.
The typical approach of modifying the config and restarting the service results in faulty behavior.
A workaround is to stop the service, modify the config and then start the service:
I rebooted. The Wiki page DHCP Configuration is correct. I am about the Wiki page Dump AP and what that suggests:
Suggested alternative B/etc/init.d/dnsmasq disable
That disables not only DHCP but also DNS internally in the OpenWrt. After that, OpenWrt itself cannot ping, openssl, or do a package update anymore.
Suggested alternative A: uci set dhcp.lan.ignore=1
That leaves an Open DNS resolver. In other words: DHCP is off, however, the DNS resolver still listens and answers to DNS queries from everywhere – the home network in case of IPv4 and the world in case of IPv6. Of course, if I have a port forwarding or exposed host targeting to that OpenWrt, even via IPv4 it is world access.
I see three approaches to rectify this. One approach would be to replace the existing two suggestions and
(a) redirect to the Wiki page DHCP Configuration section Disabling DNS role. Or
(b) copy that over to the Wiki page ‘Dump AP’. Or
(c) use my approach explained in my initial post; limiting the local DNS resolver to localhost.
Yeah ignore that. Made a mistake at the beginning (I looked for a local resolver listing on port 53 but in that case, there is no local resolver anymore). OK. The second proposal about the Open DNS Resolver, what about that?
Pardon, I am not sure, I got that. That Wiki entry is about the specific use case ‘Dumb AP’. In that scenario, when dnsmasq is still running, the DNS resolver must be limited to localhost not to create an Open DNS Resolver. There is no rationale to offer a DNS forwarder in that specific use case. Or are you about the valid alternative, stopping dnsmasq completely?
Stand corrected one more time. Just adding ‘loopback’ as interface does not solve the Open DNS Resolver issue. That is because the option nonwildcard is enabled on default which starts dnsmasq with the Jun. 2012 introduced parameter --bind-dynamicsince Dec. 2015. Consequence: After a reboot, OpenWrt listens to all added IP addresses beside ‘loopback’. Furthermore, when a new IP address is added while running, dnsmasq is going to listen on that as well. Disabling nonwildcard is no option either because then dnsmasq listens on the wildcard: all IP addresses. With UCI, I see no way to call the mode--bind-interfaces. Consequently, if dnsmasq shall run as local DNS resolver not globally accessible, editing the file /etc/dnsmasq.conf is required with
listen-address=::1,127.0.0.1
bind-interfaces
and nonwildcard aka bind-dynamic must be disabled because it is enabled on default since Jun. 2017:
uci set dhcp.@dnsmasq[0].nonwildcard='0'
Therefore, long story short, my current proposal:
The Wiki entry about the Dumb AP should be changed into:
Step 3: Disable DHCP and DNS Server
/etc/init.d/dnsmasq stop
uci set dhcp.lan.ignore='1'
uci set dhcp.@dnsmasq[0].localuse='0'
uci set dhcp.@dnsmasq[0].port='0'
uci commit dhcp
/etc/init.d/dnsmasq start
/etc/init.d/odhcpd restart
which is a copy and paste from the Wiki entry DHCP. The part about disabling dnsmasq stays as is. What about that? However, because that is a copy and paste, hard to maintain, my proposal is:
Step 3: Disable DHCP and DNS Server
If you still need dnsmasq running for something else (e.g. TFTP server) disable its DHCP server (to avoid Rouge DHCP) and its DNS server (to avoid an Open DNS Resolver). If not disable dnsmasq service completely:
Thank you very much for documenting your experience, @nALtaLEN. I have a deployment of 6 (or so) dumb APs in a commercial building, and have found the Dumb AP article's provisions inadequate (because dnsmasq begins serving on the network pointed to by the IPv6 ULA prefix, probably because of --bind-dynamic).
I think, then, disabling dnsmasq entirely is acceptable on a dumb AP; but then how is DHCP option 6 conveyed to /etc/resolv.conf?
It appears the answer is to set ln -sf /tmp/resolv.conf.d/resolv.conf.auto /etc/resolv.conf. The filepath that /etc/resolv.conf points to isn't actually managed by anything as far as I can tell.