Using RPZ allows us to mangle DNS responses so the hosts
we wish to filter return NXDOMAIN responses. This should
even prevent connection attempts.
It'll log:
unbound: [41788:0] info: RPZ applied vortex.data.microsoft.com. nxdomain 10.0.0.5@51516 vortex.data.microsoft.com. A IN
unbound: [41788:0] info: RPZ applied vortex.data.microsoft.com. nxdomain 10.0.0.5@51516 vortex.data.microsoft.com. AAAA IN
It's this kind of visibility, rather than the additional
capabilities of RPZ over returning 0.0.0.0/127.0.0.1 as
DNS responses, or rejecting TCP connection, what makes me lean
towards using RPZ.
It does add some complexity over the aforementioned alternatives
but in my view it's pretty affordable.
Ship it disabled by default.
While there, indulge myself in a drive-by commit to replace
_enabled with _enable, which is shorter and we also use
extensively in the code. Remove unneeded unbound tasks too,
as we moved to unix sockets instead.
Using RPZ allows us to mangle DNS responses so the hosts we wish to filter return NXDOMAIN responses. This should even prevent connection attempts.
It'll log:
It's this kind of visibility, rather than the additional capabilities of RPZ over returning
0.0.0.0/127.0.0.1
as DNS responses, or rejecting TCP connection, what makes me lean towards using RPZ.It does add some complexity over the aforementioned alternatives but in my view it's pretty affordable.
Ship it disabled by default.
While there, indulge myself in a drive-by commit to replace
_enabled
with_enable
, which is shorter and we also use extensively in the code. Remove unneeded unbound tasks too, as we moved to unix sockets instead.See openhrc/issues/17 for details.