Wiki: Dumb AP: DNS proxy: Local

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>

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

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 – I want, no I need that.

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:

Otherwise, it requires rebooting to apply the settings properly.

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.

This is not a common issue as the internal resolver usually works fine with dnsmasq disabled:

# /etc/init.d/dnsmasq disable
# /etc/init.d/dnsmasq stop

# readlink -f /etc/resolv.conf

# cat /etc/resolv.conf
# Interface wan
# Interface wan6

# nslookup

Address 1:
Address 2: 2a03:b0c0:3:d0::1af1:1

# opkg update
Updated list of available packages in /var/opkg-lists/openwrt_core
Signature check passed.

So, try to reproduce your problem and isolate its cause.

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?

1 Like

Yep, that can be useful if you want to keep dnsmasq as DNS forwarder for the local system:

uci -q delete dhcp.@dnsmasq[0].interface
uci add_list dhcp.@dnsmasq[0].interface="loopback"
uci commit dhcp
/etc/init.d/dnsmasq restart

That looks cool. Have to test that. If that works, a +1 from me because I prefer a local resolver. Then, the Wiki would be:

My proposal was:

/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