Per-listener or per-original-destination upstream selection in a single instance (UDP port 53 redirected via DNAT)

[engageub]

Setup

I run dnscrypt-proxy 2.1.20 inside a container with NET_ADMIN enabled. All outgoing UDP traffic on port 53 is redirected to the local resolver using iptables NAT rules in PREROUTING and OUTPUT, which DNAT the traffic to 127.0.0.1:53.

Applications inside the container, as well as containers sharing its network namespace, are configured to use public DNS resolvers such as 8.8.8.8 and 1.1.1.1. The iptables rules transparently redirect their DNS queries to dnscrypt-proxy.

My configuration includes five static DoH servers in server_names: two Google servers, two Cloudflare servers, and one Quad9 server. dnscrypt-proxy selects upstreams from this pool based on latency.

Observed behavior

When I run nslookup google.com 1.1.1.1, the query is answered through whichever upstream dnscrypt-proxy selects, rather than necessarily going through Cloudflare.

Using dig TXT o-o.myaddr.l.google.com, I can observe Google egress IPs, sometimes with an ECS line, or Cloudflare egress IPs without one. This behavior occurs regardless of which resolver address I specify in the client command.

This is expected because DNAT changes the packet's destination before dnscrypt-proxy receives it, so the proxy no longer has the original destination address available through the usual socket interface.

Desired behavior

I would like dnscrypt-proxy to select an upstream based on the resolver address originally targeted by the client, while retaining the existing upstream pool as a fallback.

For example:

• Queries originally addressed to 1.1.1.1 should use cloudflare1.
• Queries originally addressed to 8.8.8.8 should use google2.
• Queries targeting other resolver addresses, or addresses without an explicit mapping, should use the normal upstream pool.

Ideally, this should work within a single dnscrypt-proxy instance, with shared caching, connection management, and latency tracking wherever possible.

Existing approaches and their limitations

1. Separate instances for each upstream

Without modifying dnscrypt-proxy, I can run a separate instance for each upstream, assign each instance its own listen_addresses port and server_names, and configure iptables to DNAT each original destination to the corresponding local port.

This approach works, but each instance maintains its own cache, connection pool, and latency tracking. When deployed across many containers, the additional CPU and memory overhead becomes significant, making this approach difficult to scale.

2. Packet marking

iptables can mark packets using -j MARK or assign DSCP/TOS values based on the original destination before DNAT occurs.

However, packet marks and TOS values are kernel-level metadata rather than part of the DNS message. The receiving application would need to retrieve this information through socket ancillary data, for example, using SO_RCVMARK or IP_RECVTOS with recvmsg().

As far as I know, dnscrypt-proxy does not currently read this metadata, so this approach would require support within the application.

Questions

1. Per-listener upstream selection: Does dnscrypt-proxy currently support associating a specific server_names list, or a single upstream server, with a particular listen_addresses address or port within one instance? From what I can tell, all listeners share the same upstream pool, while forwarding_rules only supports matching queried domains.
2. Recovering the original destination: Is there a supported way for dnscrypt-proxy to determine the original destination address of a DNAT-redirected UDP query? For example, could this be obtained through conntrack, packet marks, or TOS/DSCP metadata on the incoming packet?
3. Potential implementation approaches: If this functionality is not currently supported, which approach would be most appropriate?I would also appreciate guidance on cache behavior. If upstream selection depends on the original destination or the selected server, would the cache key need to include that information to prevent responses from one upstream being reused for queries intended for another?
   • Add configurable per-listener upstream selection.
   • Read incoming packet marks or DSCP values and map them to upstream servers through a configuration table.
   • Retrieve the original destination address through conntrack and use it to select an upstream server.
4. Recommended alternative: Is there a more lightweight or scalable approach to achieve destination-based upstream selection without running multiple dnscrypt-proxy instances?

The existing integration is available in the test branch of Internet Income Script.

Thank you for your time and any guidance you can provide.

[jedisct1]

Maybe you can run multiple dnscrypt-proxy instances, each listening to a different port and connecting to a single server.

[engageub]

Hi,

Yes, it worked as I mentioned earlier. However, memory usage increases with the number of instances. A single instance consumes approximately 6 MB of RAM, which could have a noticeable impact at scale.

For now, this is a working solution, and I’ll update the code accordingly. However, I wanted to check whether there’s a way to avoid this additional memory overhead.

Thank you.