[DNSfirewalls] rpz firewall + whitelisting

Brian Dickson brian.peter.dickson at gmail.com
Mon Aug 26 21:01:38 UTC 2019

On Mon, Aug 26, 2019 at 1:03 PM Bob Harold <rharolde at umich.edu> wrote:

> On Mon, Aug 26, 2019 at 3:46 PM Lee <ler762 at gmail.com> wrote:
>> On 8/26/19, m3047 <m3047 at m3047.net> wrote:
>> > I've always felt best practice was (listed in order of precedence /
>> > declaration):
>> >
>> > 1) A local whitelist.
>> >
>> > 2) Any third party zones.
>> >
>> > 3) A local blacklist.
>> Seems like that would work only if you had a script to regenerate your
>> local lists after a third party zone updates.
>> I haven't tried this, but let's pretend that
>>   your local blacklist has *.2o7.net
>>   a third party blacklist zone adds  bcbsks.com.102.112.2o7.net
>> I'm guessing that your blacklist doesn't actually blacklist
>> 112.2o7.net & everything below it now.
>> & just out of curiosity - how do you troubleshoot something like that?
>>  .. besides eyeballing the rpz zones.
>> Thanks
>> Lee
> If your local list and the third party list are separate RPZ zones, then
> it should be almost fine, I think.  Each zone is processed separately, and
> the first zone that matches takes effect.  The third party would not match,
> but yours would.  I know that sounds confusing, you might want to test it.
The implementation I am familiar with, uses a bit-field (32 bits) for zone
And, it uses a well-defined ordering on the zones themselves.

So, you can have up to 32 zones in a sequence to be used with a first-found
matching, based on the order you use for the zones.

Examples would be things like:

   - absolute whitelist
   - high-quality curated blacklist
   - high-value whitelist
   - high-trust, high-quality blacklist
   - internally generated high-quality whitelist
   - medium-trust, high-quality blacklist (possibly merged from multiple
   - low-trust whitelist
   - low-quality blacklist
   - everything else passes by default, or everything else is blocked by
   default, whichever makes sense.

IIRC there is a modest performance penalty based on the number of zones you
use, but not based on the size of the zones themselves except at
load/reload time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnsfirewalls/attachments/20190826/f1be8ccb/attachment.htm>

More information about the DNSfirewalls mailing list