How to define local network router's IP in forwarding-rules not hardcoding it to particular value?

[kkovaletp]

Hi Community and Team,

I'm new to the dnscrypt-proxy and set it up for 1st time y-day on my Mac to use all advantages of DoH across the system and not only in browsers.
However, I have other devices in my local network, so I had to configure forwarding-rules to let dnscrypt-proxy forward all requests for that devices to my router directly, as advised in the documentation. It works fine at home, but if I get my Mac to my friend and join his WiFi, it stops working, as he has configured his router with different IP.

My question is: is there a way to not hardcode the router's IP in that config and use some sort of dynamic router discovery or IP resolution? The OS knows it anyway, so I assume there might be some option to put a variable into the config, which then can be resolved to the router's IP dynamically at the time, each forwarding happens...

If this is a known question, please point me to the answer, as I didn't find it.
If for some reason it is not possible, as not been implemented yet, please let me know and I'll submit a feature request for that.

Waiting for your thoughts.
Thanks in advance,
Kostiantyn.

[lifenjoiner]

This is an interesting feature that I also imagined before. But AFAIK, there is no this feature implemented, nor in other programs I've ever seen.

The OS knows a dynamic DNS from the router according Dynamic Host Configuration Protocol (DHCP).
Once, you use a specific DNS, you had set your device's DNS static. I don't know if the OS still has the uptodate DNS from the DHCP server.
If not, extra DHCP library will be required. Can a single program claim as a DHCP client and send DHCP messages? Safe?

[ZzZombo]

Can a single program claim as a DHCP client and send DHCP messages? Safe?

It should be. In fact, that's how WPAD using DHCP is supposed to be implemented, there is no way other than by sending a specific DHCP query and listening to the response.

[kkovaletp]

The OS knows a dynamic DNS from the router according Dynamic Host Configuration Protocol (DHCP).

DHCP is (AFAIK) the most popular LAN configuration way and local DNS discovery using DHCP looks like a straightforward approach in this case. However, the OS already has that info and in theory, the app can send the request to the OS to get it.

What if there is no DHCP and we have manual network configuration for some reason? I don't know whether this case is even could be found in real life these days... But technically it is possible. What options do we have here? If we have manual network configuration, asking the OS looks like the best option, but there is no guarantee that the gateway has DNS on the same IP (as well as we couldn't be sure that the DNS even exists in this LAN). What will happen if the app will send some broadcast request in the LAN and if there will be a response, that IP would be considered a DNS? What could we do if there is no DNS at all and network nodes use some simple network lookup / WINS for name resolution? Could the app have some small and simple DNS to handle that?

These are just my thoughts... Maybe they will help you to better see the area and find a solution...

[lifenjoiner]

Let's do some experiments first:
Try this CLI demo to see if it works for you.
If there is no binaries for your platform, compile it yourself with the dev branch.

[lifenjoiner]

On Mac, here shows 7/10 got.
There seems to be a system DHCP client occupies the :68 exclusively, at OS up or when the network state changed, maybe aperiodic.

[kkovaletp]

occupies the :68 exclusively

I don't know for sure, but I have DNScrypt-proxy installed on my Mac and all DNS requests are forwarded through it. Maybe that is the reason.
BTW, after that test, I had to reboot my Mac, because after some time I noticed that new DNS requests were failing and DNScrypt-proxy's query log contains a lot of requests with NETWORK ERROR.
After reboot it is fine. Maybe your experimental code did some config changes, which were not reverted on process exit...

[lifenjoiner]

The demo does nothing special more than the package name saying: DHCP communication, requesting the DHCP server (router) for the DNS.

BTW, after that test, I had to reboot my Mac, because after some time I noticed that new DNS requests were failing and DNScrypt-proxy's query log contains a lot of requests with NETWORK ERROR.

If not all requests failed or if you can still visit the web, that should not be an issue caused by this.
If you lost your connection completely, that will be the problem, and just reconnect will solve it I guess.

I don't have a Mac to test.
On Windows and Android, the connection is unaffected.

[kkovaletp]

If not all requests failed or if you can still visit the web, that should not be an issue caused by this.
If you lost your connection completely, that will be the problem, and just reconnect will solve it I guess.

There is a DNS cache, so all typical hosts are already known and no requests were sent for several hours, that is why I didn't notice the problem right after the testing.
I have wired and wireless connections and tried to reconnect both of them (subsequently and at the same time) with no effect, also I tried to restart DNScrypt-proxy, but only the system reboot helped.

[lifenjoiner]

A potential issue should be fixed. That's all about DHCP.
On Mac, it seems not as reliable as on Ubuntu nor Windows.

[lifenjoiner]

One more step, here is an alpha version extending forwarding on my branch.
Anyone is interested can have a try and help improve it.

[dodmi]

Hello, thank you for implementing this. This sounds really great and helpfull. I'll gladly test it, as I have different problems with some public WLANs, using captive portals, where the portal site is only resolvable from the provided DNS.

[dodmi]

I just want to add: It seems to work great on my local network; platform is Windows x64

[dodmi]

After some testing: It works as intended for all other networks. Thank you ;)
Only problem with captive portals: Any domain lookup will be redirected to the captive portal, so you need to open the captive portal manually, since we don't want to send any lookup to the DHCP dns server.

[lifenjoiner]

More tests appreciated:

1. IPv6 DHCP. I have a buggy router from an ISP, which provides IPv6 occasionally and limited DHCP.
2. Running as a non-root user on Linux.

An alpha version extending forwarding on my branch.

[designgrill]

Thanks for working on this @lifenjoiner. Any idea if this is getting merged any time soon?

This would be a very useful feature, especially for Captive Portals whose IPs are not known before hand. I feel it is much easier to put a domain through the DHCP DNS than to try to figure out the IP behind a captive portal without compromising the rest of the traffic.

[lifenjoiner]

I respect Frank as decision maker, and also keep radical features in my branch.