[FR] Support ECS Data for access-control-view and tag Assignments

[Hexen1988]

Description:
Currently, Unbound’s access-control-view and tag assignments operate solely based on the source IP address of incoming DNS queries. This behavior limits the ability to apply different policies or views for clients where ECS (EDNS Client Subnet) data is present in the query.

It would be highly beneficial to introduce functionality that allows access-control-view and tag assignments to consider ECS data when present. This enhancement would enable more granular policy enforcement for DNS queries, especially in scenarios where clients communicate through public IPs, but ECS data reflects their private subnet.

Key Benefits:
1. Improved Policy Control: By considering ECS data, Unbound could dynamically apply views or tags based on the client’s private subnet (e.g., internal users behind NAT).
2. Enhanced Use of RPZ: This feature would allow Response Policy Zones (RPZ) or other filtering mechanisms to better align with ECS data.
3. Flexible Network Scenarios: Supports more complex network environments where source IP alone is not sufficient to determine policies.

Proposed Implementation:
1. Extend access-control-view to include optional ECS-aware logic.
• If ECS data is present, prioritize it for view assignment.
• Fallback to source IP if no ECS data is provided.
2. Allow tag and tag-actions to utilize ECS data for conditional assignments.
• Introduce a new configuration option (e.g., ecs-access-control) for enabling this feature.
3. Include a configuration flag to toggle ECS consideration for these features, ensuring backward compatibility.

Use Case Example:
In a corporate environment, clients from private subnets (e.g., 10.0.0.0/8) access DNS resolvers via public NAT IPs. By embedding ECS data, Unbound could:
• Apply private network views (view_private) for these queries based on ECS.
• Assign tags like internal_user for targeted filtering or response policies.

References:
•
• Related GitHub issue: #573.

This enhancement would significantly expand Unbound’s flexibility in modern network environments where ECS data is increasingly used for client-specific DNS resolution.

[Hexen1988]

Any comment ???

[wcawijngaards]

Thank you for the suggestion. Not sure if the config of unbound needs the complication, and if EDNS subnet is really good for that; eg. that expresses some criticism for the use of EDNS subnet. But there are many packet-tagging techniques in places. Maybe this is a useful feature, though.

Unbound supports proxy traffic and then it does, I think, what you need here, just using a different technique to mark the packets. The option to enable it is proxy-protocol-port: <port number> and https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-proxy-protocol-port is documentation on it.

[Hexen1988]

Thank you Dr Wouter for the suggestion. I believe that using external proxy to achieve will result in loosing the original Source IP which is also crucial in my scenario.

The reason I have raised this is that I am currently using Unbound to provide DNS Firewall services to my clients, leveraging a custom-built endpoint agent that forwards DNS queries to Unbound with the ECS option enabled for visibility purposes.

I am facing a challenge with the access-control-tag option. Applying RPZ policies solely based on the source public IP causes all endpoint clients within the same network (and sharing a single public IP) to be grouped together. This results in RPZ rules being applied uniformly to all clients in that network, which is not ideal.

To address this issue, I am exploring the possibility of combining ECS and source IP to assign more granular RPZ policies to incoming queries.

I would like to ask if there is any workaround for this issue that does not involve modifying Unbound’s source code. Additionally, is there any chance of introducing such an enhancement as a feature request in the future?