Add "DNS" setting to static lease configuration

shodanx · February 14, 2023, 4:50am

This is a companion request to Add "default gateway" setting to static lease configuration

In some cases, it might make sense to point certain devices to difference DNS servers

For instance I might have google's dns, my ISP's dns, a pihole, my VPN's DNS and other DNS with special exclusion list, for instance a dns server that will not resolve any of Microsoft's, apple's, facebook's and all of China's DNS records.

And it would be helpful to switch certain devices between each of those choices from the static lease configuration page.

Here is what that might look like

Like the other feature request, the list of DNS servers might be a little drop down menus where you can select from a multitude of known DNS servers.

lleachii · February 14, 2023, 12:50pm

What's wrong with the standard, OpenWrt and RFC-method way of doing so?

shodanx · February 15, 2023, 6:34am

Cannot be done in the interface, as shown in screenshots, the option is missing

lleachii · February 15, 2023, 7:06am

Unless I've mistaken, you're literally showing it in your screenshot.
I'm guessing you mean web interface (can't determine since you show it)?

You may want to clarify and provide more details.

Are you asking for OpenWrt to "guess" public DNS servers people wish to use, and then have a pre-screened list already added?

shodanx · February 15, 2023, 9:56am

The screenshot is a fabrication of how it might look like.

Just having a place to enter alternative, per lease DNS would be great.

Having a drop down would just be a quality of life improvement on top.

As for populating this list, it could include,
the DNS offered by ISP from the dhcp client on the WAN port
Other alternate DNS already named in /etc/config/dhcp
These four highly popular public dns servers
8.8.8.8 (Google Public DNS)
8.8.4.4 (Google Public DNS)
1.1.1.1 (Cloudflare Public DNS)
9.9.9.9 (Quad9 Public DNS)
Maybe others curated by openwrt dev team
etc...

lleachii · February 16, 2023, 12:37pm

These are already used by default, why is a dropdown needed?

It's extremely poor practice to hard-code IPs. It even borders legal liability issues since these IPs don't belong to them. There's a bad history of hard coding servers that dont belong to the developer into software.

Some people are leary of these companies for that very reason (i.e. highly popular). There's a few threads of peope blocking these IPs.

shodanx · February 20, 2023, 3:57am

I have just tried multiple ways of defining DNS for the static lease, and this also is extremely difficult to figure out without it being supported in the web interface.

In all attempts, I have never managed to change the DNS on the device
I was trying to make it "0.0.0.0" as this android device is said to stay connected to a wifi network without internet if it has a DNS of 0.0.0.0. I don't know if this is true, however, I have never managed to get anything other than 192.168.1.1, my router's current address to fill in as the DNS.

As show in this screenshot

Here all of my attempts

First I tried just having the DNS in a tag entry

This had no effect on device dns

Then I tried changing the option dns

Then I tried just any other address for the dns, maybe 0.0.0.0 was breaking things ?

Then I got rid the of option tag

Still no go

I tried removing option dns entirely

And lastly I tried re-adding the dns in the tag only

And you know what, I was ready to throw in the towel

It's been hours of messing around

But that last one finally worked

I tried putting 3,0.0.0.0 in the tag, but then it reverts back to 192.168.1.1

So the phone still won't stay connected ...

Anyway, all this to say, it would have been so much nicer to have those settings in the web interface and not waste my sunday doing this and it still not working ! How many other people will waste their sundays on this !

Edrikk · February 21, 2023, 6:55pm

I think you may have a few different things going on here; Some related to under understanding the wiki info, secondly it is Client device behavior, and finally some for sure related to "ease of setup".

This is probably the longst post I've ever writting. So I'll say it up top: If you wish, I can share my setup. But I think the below is important potential details as to why a whole day was "wasted" ...

First item (reading wiki):
In terms of the things you've tried, the dhcp wiki shows that you can't use the option dns as you have done. It is not (and cannot be) the IP address of the DNS Server you want the host to use.
The valid values are 0 and 1. The value 1 allows for forward and reverse DNS lookups. See this commit.
Seems the wiki wasn't read/understood before trying things that would have saved a lot of time - specially the data type element.

So in short, all of the things you tried, except for the first one had no chance of working to start with... The wiki table I linked to shows that ... given that it shows the data type is a boolean (not an address), and that the default value is a 0 (again not an ip address).

Second (Client behavior):
Assuming you stopped dhcp/dns dnsmasq server after saving AND restarted/forced an IP update from the device (e.g. by putting in airplane mode and returning), AND you didn't use 0.0.0.0, then off the top of my head this first one should have worked.

I see you're doing this for an iot camera in your config based on the name. If that's the case, you'll probably save a lot of time setting it up for something quicker / with more control on refresh of config... e.g. your computer. But be aware that some clients (e.g. iphones) I believe wont connect to a network if the DNS checks for internet connectivity don't succeed.

If you actually used 0.0.0.0, well, this again points to not properly searching what it means.... Especially since your android also indicated that it treats 0.0.0.0 DNS "differently."

First google result for "dns 0.0.0.0" shows that it is not a valid value, and that the client will likely choose what to do. So the device is at that point deciding when to use the gateway IP or router IP for DNS based on whatever logic it has internally.

Third point (ease of use):
I get what you're trying to do, but I'm not sure this is the right way to do it. I have a very similar thing setup where some devices are tagged to go through pihole for parental control DNS offered by cloudflare. Given that the DNS is functional, it works.

I also have devices that I don't want to talk to the Internet (which I believe is what you're trying to acheive here). I also use tagging for this purpose, but for the purpose of giving these devices IPs in a specific range. This range I consider as "no internet".
In turn, you would use firewall rules to drop the packets from this range.

If you wish, I can share my setup.

lleachii · February 22, 2023, 12:15pm

It seems you are intentionally adding invalid values. Additionally, we can't troubleshoot your Android, especially given you're intentionally placing bad DNS and gateways.

FYI for if this gets added as a New Feature - invalid entries wouldn't work on the web GUI either (the developers have been working on ensuring boxes are configured to accept only valid entries).

Recall, dropdowns could only have valid options anyways.

shodanx · March 6, 2023, 2:54am

Hello,

I don't have a full reply but a few points

The openwrt dropdown supply known options and at the end, there is a space for custom entries

Yes, this is what I was trying to do, I am trying to give these android devices local network access but limit or prevent their internet access entirely.
These devices may permanently update their firmware without user permission and cripple themselves if given the chance to freely talk to the internet. So I'm trying to restrain their access but also keep them connected to the local wifi.

Plugging in 0.0.0.0, at an earlier time, would have fooled them into thinking there was working internet even if it didn't work. However, as I found out, in android 9 this is no longer the case, dns of 0.0.0.0 no longer is sufficient to prevent the behaviour.

I think I will have to figure out how to use the fakeinternet package.

As a temporary workaround, I have filled in all my 30 or so devices with static address. Which is a huge logistics problem for future me, but it works for present me.

This is sound advice, however I try to avoid IP-based rules if I can due to processor limitations on my router. I have gigabit internet and a slow router. I like having a reliable low power router like the Archer C7 for now but I know at gigabit speeds, this router will easily be overwhelmed if I put too many rules in place.

That is why I was investigating controlling DNS with the DHCP static lease interface

Although all this is getting very off topic to this feature request.

What I really would like to see is an option in the static lease part of the luci web interface, an option to override DNS easily for specific devices.

For the record, the following solution of creating a manual tag works, at least for a windows device

config host
        option mac '3C:XX:XX:XX:XX:C8'
        option name 'windows-device'
        option dns '1'
        option tag 'deadend_gateway'

config tag 'deadend_gateway'
        list dhcp_option '3,192.168.1.254'
        list dhcp_option '6,192.168.1.253'

Edrikk · March 6, 2023, 4:02am

I personally wouldn't go through the trouble of setting static IPs on each device - static DHCP is much better approach I find (whether to give only in a specific range, or specific IP)... That's a significant lift, and I'm not a fan of hardcoding things like that on edge devices. For example, last year I changed my IP address range and subnet. This was more or less effortless as the changes took place only on routing devices.

Here's my setup which may help. I would give it a try... I can't imagine this adding much load on your router to be honest.

As I run miniupnpd (UPNP), I also drop the UPNP open requests. This shouldn't be needed given that the traffic is dropped, but I have included it:

/etc/config/firewall - also configurable in Luci's firewall page under "traffic rules" tab

config rule
        option src 'lan'
        option dest 'wan'
        option target 'REJECT'
        list src_ip '192.168.40.0/25'
        option name 'IoT No Internet (192.168.40.0 to 127)'

config redirect
        option target 'DNAT'
        option src 'lan'
        option src_dport '53'
        option name 'DNS Intercept Requests'
        option reflection '0'
        option dest 'wan'

/etc/config/upnpd - also configurable in Luci's upnp app.

config perm_rule
        option ext_ports '0-65535'
        option int_ports '0-65535'
        option action 'deny'
        option comment 'Deny IoT (192.168.40.0 to 127)'
        option int_addr '192.168.40.0/25'

Below are two examples. In first, I let an IP be provided to the device within the "allowed/reserved/known" range based on the tagging. In the second, I have provided a specific IP address in this no internet range, but outside the DHCP IPs in the range.
The reason for the static DHCP is that after a reboot some devices don't renew their IPs fast enough, and so can be unreachable (depends on the device).

/etc/config/dhcp

config host
        option name 'Device 1'
        option dns '1'
        option mac '34:EA:XX:XX:XX:XX'
        option tag 'iot-no-internet'

config host
        option name 'cam-garage'
        option dns '1'
        option mac 'E0:B9:XX:XX:XX:XX'
        option tag 'iot-no-internet'
        option ip '192.168.40.10'

Also within dhcp config file (in Luci, it's under the interface's DHCP Server tab, except for the dhcp_option, which has to be hand typed in the config file). Note that the dhcp_option is actually not needed for this example. But I left it in because I use the "kids" tag to send the kids to a pihole DNS instead of the openwrt DNS:

config dhcp 'lan'
        option interface 'lan'
        option dhcpv4 'server'
        option start '522'
        option limit '191'
        option leasetime '3h'
        list dhcp_option 'tag:kids,option:dns-server,192.168.41.11,192.168.41.1'

Last thing for the /etc/config/dhcp configuration file, the below option must be added,

config dnsmasq
        option confdir '/etc/dnsmasq.d'

Now moving over to /etc/dnsmasq.d directory, I have created a text file called additional.conf which simply contains this line; You could add additional line for each tag). This tells dnsmasq to serve only this range for the given tag:

dhcp-range=tag:iot-no-internet,192.168.40.20,192.168.40.127,3h

I think that's it... Nothing to do on the devices.

shodanx · March 6, 2023, 4:20am

Thanks,

In this configuration, is this enough to fool the devices into thinking they have internet access, even they don't ?

In my case, android devices pointed to dead end gateway and dns, figure out they don't really have internet access and they disconnect from the wifi.

About the firewall, doesn't that mean the router has to evaluate

list src_ip '192.168.40.0/25'

For every single packet ? I imagine that with 1gbps of traffic, this will amount to an extra heavy CPU burden ?

Edrikk · March 6, 2023, 5:27am

I’m sure it’ll be fine. Anyways, only one way you’ll know how it works in you specific setup.

Yes, my setup does not deliver packets to the internet for the specified devices.

As for “fooling” devices, you’re not going to “fool” a device. If the developers of the device logic didn’t want it to work without what they implemented as their test, it’s not going to function.

castillofrancodamian · March 10, 2023, 10:05pm

@shodanx @lleachii There is a PR that implements what you want to do in this post.

shodanx · March 11, 2023, 9:41am

@Edrikk

By "fooling a device" I really mean, doing the necessary to circumvent what test the device does to determine it has freely access to the internet when it does not.

Hostile operating systems such as android and microsoft windows will act against user's wishes without permission and will nag and malfunction when restricted from accessing the internet in various ways.

So far the "fake internet" package seems like the only hope of fooling these. The various internet lore, which suggest things like setting a DNS of 0.0.0.0 don't work, at least for android 9 and windows 10. It might have worked on earlier version that didn't have as sophisticated call home features.

@castillofrancodamian
Thank you for the heads up. I will see if I can import these changes to my installation and test them.

Edrikk · March 11, 2023, 12:45pm

Yes, but the behaviour will be device dependent.
Once you install and setup please report back. Would love to know how it went / if it worked / etc.

Good luck’