I’m currently building a DNS filtering service using Unbound and a Python module. My service should only respond to IP addresses that are listed in a database; these can be added dynamically. Is there a way of existing out of the python module so that nothing is sent back to the client if their IP isn’t in the list?
I have already got the users IP address, and have written some code to check it against the databse. My issue is that if the IP doens’t exit then all I can do is set “qstate.ext_state[id] = MODULE_ERROR” which will return a “status: SERVFAIL”. Is there a way of returning nothing at all?
Could you describe the application of your request a bid more broadly?
What is the problem you are trying to solve?
From what you're telling us right now, Id gather that you have a dynamic
list of clients that you want allow talking to unbound while denying
everybody else, and managing 'access-control' statements in unbound.conf
is too cumbersome.
Sounds like you want a cron job plus ipset/iptables, custom python code
for unbound is the wrong tool for the job.
Kind regards,
Tom
another way to solve this is with rpz, which is now available for
unbound (farsight fastrpz for unbound: free of charge, not open source,
available to FSI-pDNS sensor operators or to commercial support
customers of opennetlabs.)
with rpz you could set up a policy zone that all of the unbound servers
in your recursive cloud subscribed to. in it you would say that
client-ip 0.0.0.0/0 and 0::/0 were disallowed (either drop all queries,
or always answer nxdomain, or always answer cname, or whatever) and then
add specific client-ip address blocks for your subscribers, with
passthru actions.
it's not exactly what rpz was designed for, but it would work.
and it makes me realize that we need a soft passthru: skip the other
rules in the current ruleset, and continue down the rpz zone list,
rather than continuing with policy-free resolution. after all, it's
possible you'd want your customers to be protected by real security-
related response policy.
https://dnsrpz.info/ has more information about rpz in general, which is
not encumbered at the specification level. i regret any offense given by
the mention of non-open-source technology here.
vixie