No ECS with --edns

[s-hamann]

Summary

Either I do not understand how --edns/EDNS Client Subnet support is supposed to work or it does not work as documented.
I run dnsproxy with --edns (but without --edns-addr) and dnsproxy does not send a client subnet to the upstream.
According to the readme, it should:

To enable support for EDNS Client Subnet extension you should run dnsproxy with --edns flag:

./dnsproxy -u 8.8.8.8:53 --edns

Now if you connect to the proxy from the Internet - it will pass through your original IP address's prefix to the upstream server.

What I'm trying to do

I run a local recursive DNS resolver as well as a local authoritative name server for the internal network zone (example.com).
I want to use dnsproxy to provide a single interface to both (and also provide DoT, DoH, etc. to clients).
As the authoritative name server does some split horizon answering based on the client's subnet, I want dnsproxy to pass that information on.

My setup

I run dnsproxy v0.65.2 on OpenWrt 23.05.2.
The resolver as well as the authoritative name server run on the same system, listening on port 5301 and 5302, respectively. Those are not supposed to be reachable from the network, but they are for now so I can debug the setup.
I run dnsproxy like this:

dnsproxy --listen 0.0.0.0 --listen :: --upstream 127.0.0.1:5301 --upstream [/example.com/]127.0.0.1:5302 --edns

My observations

From a different system, I ran some queries with dig, captured the DNS traffic on the OpenWrt system and analysed it using Wireshark.

1. Query dnsproxy:

dig @192.0.2.1 host.example.com

• Query from client to dnsproxy does not contain ECS option (of course)
• Query from dnsproxy to authoritative name server does not contain ECS option (bug?)

2. Query authoritative name server with client subnet:

dig @192.0.2.1 +subnet='192.0.2.5/24' -p 5302 host.example.com

• Query from client to authoritative name server contains the CSUBNET option (of course)

3. Query dnsproxy with client subnet:

dig @192.0.2.1 +subnet='192.0.2.5/24' host.example.com

• Query from client to dnsproxy contains the CSUBNET option (of course)
• Query from dnsproxy to authoritative name server contains the same CSUBNET option

The latter surprised me, since #166 indicates that this should currently not work. Also, I don't want clients to be able to pass arbitrary client subnets to the authoritative name server.