Second upstream_private for vpn clients and split-dns

[paukstis]

Hi Frank, this would be useful for clients with vpn where upstream has split-dns, when client comes with public IP it goes to main upstream, and when vpn is on and client comes with reserved IP it would use different upstream. Open to discuss it or to try to make it cleaner (I'm learning Rust), if you think it's ok.

[paukstis]

About to close this PR, maybe a cleaner way is to with EDNS Client Subnet option, as mentioned in issue #32

[jedisct1]

Or you may just want to run two instances, one listening to a private IP address, and the other one on a public IP.

That way, in addition to using different upstreams, you can use different limits, different filters, have separate metrics, etc.

[paukstis]

Yes, so client would have 2 static sdns: entries, one for public, other for private IP, and would randomly talk to public or private upstreams, seems a bit confusing. The idea would be to have a single entry and transparently talk to either private upstream, when VPN is on, or to public one, when VPN is off. How about a small PR to optionally allow server to push client IP via EDNS ECS option ? Upstream could then use it to adapt reply with split-dns.

[jedisct1]

If the server is only listening to a public IP address, it will never see your private IPs. There's NAT in the way.

ECS support could be useful (and let the client provide it), but that may require a little bit more than a small PR. A response is going to be valid only for a specific client subnet, so it can't be cached in a global cache any more.

[jedisct1]

Also, if the intent is to resolve host names that are only served by a local resolver, isn't dnscrypt-proxy forwarding enough?

[paukstis]

Forwarding is cool, but needs VPN connected, when VPN is off it would not work. The intent is to have a single trusted sdns source which is reachable from Internet on public IP (NAT, VPN off), and from inside network (no NAT, VPN on, and firewall redirects traffic for public IP to internal IP).