Can I enforce cloaking rules only for certain clients?

[crichez]

Hi! I'm running a dnscrypt-proxy on my box/router at home, and used to have a cloaking rule that resolved my domain as 192.168.1.1 to make my services available to LAN clients. When I added a VPN to encrypt & route all my traffic through home when I'm away, I had to remove that cloaking rule because the local address would get cached by client devices, and I couldn't reach my services shortly after leaving the VPN. I replaced it with a destination NAT rule and everything was dandy.

Except now, a service I have running on loopback isn't working. Requests are going out to my WAN IP and timing out, even with an equivalent NAT rule in place for that interface. This is really weird, but I looked around and I don't really know how to fix it without returning to what worked previously: cloaking.

To make this work, I need my cloaking rules to only apply to requests from 127.0.0.1, but I don't see a way to do this with configuration alone. Can I run two instances of dnscrypt-proxy bound to different addresses? Do I need to chroot? Or containerize? Or am I missing something simpler?

[lifenjoiner]

Explain your Network Topology clear, I guess.

[o101010]

Hi,

Just some ideas that could help you.

• You can reduce the DNS TTL for those records. I don't think DNSCrypt-proxy is able to do that. You can setup a forward server to a "real" local DNS server.

• On Palo Alto NGFW, we have something called Policy Based Forwarding (or PBF). Those rules are applied before reading of route table and can redirect a request to another host or interface depending on source and destination ip and application. Maybe you can try to find something like that on your router. So, you don't need cloaking any more.

EDIT : You can setup a TTL for cloacking in your configuration file

[crichez]

Thanks! It seems like you're right, dnscrypt-proxy alone isn't enough for what I'm trying to do. I ended up using unbound as a local recursive server in front on dnscrypt-proxy. Unbound allows different local records to be returned depending on the address of the requesting client. By then forwarding everything else to dnscrypt-proxy I can solve my problem and still secure outgoing requests.

I already implement some PBF rules that forward requests to my global address to appropriate local ones. This is what I called "destination NAT" in the original post. It worked great! The problem here I suspect, is that one of my daemons was rejecting connections because I was whitelisting using a FQDN (for TLS reasons, I know it's silly to use TLS locally but I truly cannot figure out how not to for this particular daemon). When resolving the name, a global address was being returned, which of course didn't match the local address the connection is actually coming from.

So now when this daemon on loopback requests my FQDN A record from the Unbound server at 127.0.0.1, it responds with 127.0.0.1 appropriately. If it requests anything else, the Unbound server forwards that request to dnscrypt-proxy. Works perfectly!