<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 1:03 PM Bob Harold <<a href="mailto:rharolde@umich.edu">rharolde@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_-143445890431427160gmail_signature"><div dir="ltr"><div><br></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019 at 3:46 PM Lee <<a href="mailto:ler762@gmail.com" target="_blank">ler762@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/26/19, m3047 <<a href="mailto:m3047@m3047.net" target="_blank">m3047@m3047.net</a>> wrote:<br>
> I've always felt best practice was (listed in order of precedence /<br>
> declaration):<br>
><br>
> 1) A local whitelist.<br>
><br>
> 2) Any third party zones.<br>
><br>
> 3) A local blacklist.<br>
<br>
Seems like that would work only if you had a script to regenerate your<br>
local lists after a third party zone updates.<br>
<br>
I haven't tried this, but let's pretend that<br>
  your local blacklist has *.<a href="http://2o7.net" rel="noreferrer" target="_blank">2o7.net</a><br>
  a third party blacklist zone adds  <a href="http://bcbsks.com.102.112.2o7.net" rel="noreferrer" target="_blank">bcbsks.com.102.112.2o7.net</a><br>
I'm guessing that your blacklist doesn't actually blacklist<br>
<a href="http://112.2o7.net" rel="noreferrer" target="_blank">112.2o7.net</a> & everything below it now.<br>
<br>
& just out of curiosity - how do you troubleshoot something like that?<br>
 .. besides eyeballing the rpz zones.<br>
<br>
Thanks<br>
Lee<br></blockquote><div><br></div><div>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. </div><div><br></div></div></div></blockquote><div><br></div><div>The implementation I am familiar with, uses a bit-field (32 bits) for zone membership.</div><div>And, it uses a well-defined ordering on the zones themselves.</div><div><br></div><div>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.</div><div><br></div><div>Examples would be things like:</div><div><ul><li>absolute whitelist</li><li>high-quality curated blacklist</li><li>high-value whitelist</li><li>high-trust, high-quality blacklist</li><li>internally generated high-quality whitelist </li><li>medium-trust, high-quality blacklist (possibly merged from multiple sources)</li><li>low-trust whitelist</li><li>low-quality blacklist</li><li>everything else passes by default, or everything else is blocked by default, whichever makes sense.</li></ul><div>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.</div></div><div><br></div><div>Brian</div></div></div>