[RPZ] Whitelist rather than Blacklist

Vernon Schryver vjs at rhyolite.com
Sat Mar 9 01:02:35 UTC 2013

> From: Andrew Fried <afried at isc.org>

> Well, dynamic RPZ lists are designed to block badness in a timely
> manner.  There are companies that are able to aggregate threat data in
> real time and push out RPZ lists very quickly.  I'd strongly suggest
> that anyone looking to implement RPZ should start off with a commercial
> feed from Spamhaus and/or SURBL, then add their own listings or
> additional feeds on top of those.   Both of those lists are constantly
> updated in near real time. 

An alternative to merging data from two or more sources into a single
policy zone is using several policy zones.  The second or "rpz2" patch
for current versions of BIND9 makes multiple policy zones cheap.  It
builds and uses a summary of all policy zones instead of checking zones
one after the other until finding a hit.  That patch can be found by
following the link labeled "Patch files for BIND9" on the RRL page at

> Whitelisting has it's place for specialized circumstances, but I
> personally would suggest against doing that unless absolutely
> necessary.

I think there are two notions of whitelisting here.  It seems
generally good and prudent to have a first, local policy zone
whitelisting your own domains by name or address (rpz-ip) or your
own DNS servers by IP address (rpz-nsip) or name (rpz-nsdname).

I also doubt the general utility of the second notion that is
whitelisting part of the Internet with one or more policy zones and
blacklisting everything else in a final polizy zone.

I might be biased about the second notion.  I gave up on the dnswl.org
whitelist for SMTP, because even the most conservative subset leaked
much more spam into my personal mailbox than it stopped false positives.

Vernon Schryver    vjs at rhyolite.com

More information about the DNSfirewalls mailing list