Seems to be the "SUBNET" option in the Unbound port. I'm a little undecided here. We don't use it. I haven't heard of it before and this is the first time it's being asked for.. needless to say FreeBSD does not have this enabled by default.

Cheers,
Franco

ECS support allows for sending sanitized information to assist with geolocation and appropriate responses for CDN backed resources.

https://www.akamai.com/blog/developers/introducing-new-whoami-tool-dns-resolver-information

Enabling this module would be very helpful for people to retain some anonymity without incurring the quite real possibility of being routed to IPs that are located very far away while servers very near could be used. The performance improvements are quite real. Enabling the module in build will not expose any more information by default, it is up to the individual user/admin to configure the extent of the masking.

https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#edns-client-subnet-module-options

I'm happy to enable the option but what is the plan for integrating this? For one overriding module-config isn't easily possible at the moment and the Python module may be interfering.

Thanks for the reply. Basically for Pi-hole use (I'm the co-founder), we can point Pi-hole at the unbound instance, set unbound to do EDNS-0/ECS and pass a user-defined subnet mask. Where this helps is mostly with CDN content, as it is now there is no real mechanism to let the authoritative resolvers know where to consider the client's location. A common complaint/issue that gets assigned to DNS is increased latency. It's not DNS of course, but it is the client getting an IP that is not local.

The added capabilities are not limited to sinkholes like Pi-hole, they would help with anything that uses unbound in recursive configuration.

dan@Viking:~$ dig +short TXT whoami.ds.akahelp.net
"ns" "172.90.x.y
dan@Viking:~$ dig +short TXT whoami.ds.akahelp.net @192.168.88.254
"ns" "172.90.x.y"
dan@Viking:~$ dig +short TXT whoami.ds.akahelp.net @1.1.1.1
"ip" "172.88.0.46"
"ecs" "172.88.0.0/24/24"
"ns" "172.70.213.100"

In the above example the first two dig calls are to the system DNS resover and then the OPNsense unbound resolver in it's current mode.

The last is a dig direct with ECS data passed. The IP is not the actual client IP but a random IP that is located in the subnet passed with the query. Recursive resolvers don’t send the actual client IP they observe, in order to reduce the privacy impacts of ECS.

Edit: There is no need to override module-config. You can enable the module and nothing will change unless you include the additional configuration directives. Everything is set to default off by unbound. I don't think you'd even need to expose the configuration lines on the web interface at the start, adding in config snippets in a .d/ subdirectory should be enough for power users to get started.

Edit2: Sorry for the edits, here is an example of the potential use in action: https://www.reddit.com/r/pihole/comments/17v56cd/pihole_with_unbound/

@dschaper

It sound very good! I hope it will enable it.

Hi,
Small note to add to the discussion that if Unbound is compiled with --enable-subnet the default module-config: value changes from "validator iterator" to "subnetcache validator iterator".
Although from a privacy perspective Unbound does not enable any ECS options, the presence of the subnetcache module alone does change client query aggregation as every client query needs to be inspected individually wrt ECS.
Based on the incoming traffic that could translate to lower resolution performance compared to a default Unbound configuration without --enable-subnet.
So, if Unbound is compiled with ECS support, make sure to explicitly set module-config: "validator iterator" to keep the previous default and have no surprises to other users.

So, if Unbound is compiled with ECS support, make sure to explicitly set module-config: "validator iterator" to keep the previous default and have no surprises to other users.

I think the previous comment(s) would prevent this option.

For one overriding module-config isn't easily possible at the moment and the Python module may be interfering.

So explicitly setting the module-config to disable subnetcache means compiling with --enable-subnet would be useless.

Support for this one!
The lack of ECS is the only reason I run a separate unbound server at the moment.

Also support for this request!

Also support!

For Telephone System's very important!
Many Telecom Providers need ECS für discover the SIP-Server

I would also like to see this feature enabled. As I understood we need to compile with --enable-subnet and then add another checkbox in the options and to set module-config: "subnetcache validator iterator" if enabled., right?
Do we need a pull request for this?