Hi Tomas,

I can do you one better.
ACL per interface is going to be included in the next feature version of Unbound (somewhere in September). I would probably have a PR ready this week which will be ready to be merged on master.

I will update here when the PR is ready.

Best regards,
-- George

On 29/08/2022 10:33, Tomas S. wrote:
Hi George,

is there any chance You could help merge acl_interface

branch to 1.16.2?

util/configparser.c, util/configlexer.c and daemon/daemon.c

fails to patch.

On 2022-07-05 19:21, George Thessalonikefs via Unbound-users wrote:
Hi Tomas,

There is ongoing work that we call acl per interface.
This applies all the same logic of the access-control directives but for the listening interface(s) instead.

It is being worked on a separate branch:
    https://github.com/NLnetLabs/unbound/tree/acl_interface

This will be part of the next Unbound *feature* release (circa September).

It should be ready, pending review near the release date.

If you want to already test I can provide some quick documentation:

- each access-control-* option you could previously use per client-ip
  you can now do the same per listening interface with interface-*.
  Note: The "access-control:" directive is named "interface-action:"
- if you mix and match access-control* options and the new interface-*
  options, the access-control* options always overrule the interface-*
  options as they are considered more specific (targeting clients
  instead of the whole interface).
- The interfaces used in the interface-* options must have been already
  defined with the interface: directive.

The unbound.conf man page and the example.conf file should provide most of the information you would need.

Let me know if it works for you.

Best regards,
-- George


On 04/07/2022 10:53, Tomas S. via Unbound-users wrote:
Hello,

we are implementing recursive DNS service with a multiple RPZ zones,

where user can decide which policies to use by selecting one of multiple DNS servers IPs

(think cloudflare 1.1.1.1 - default, 1.1.1.2 - with malware blocking, 1.1.1.3 - malware+adult blocking).


To implement this (in one server) one could run multiple unbound instances,

but rpz: unbound configuration already supports tags, however, tags can only be set

by client source IP.


I'm thinking about adding one more access-control directive: like access-control-tag,

but for destination IP (lets say access-control-dest-tag).

Do you think it would be a reasonable approach?


Best Regards,

Tomas

Reply via email to