[RPZ] Whitelist rather than Blacklist

Paul Vixie paul at redbarn.org
Sat Mar 9 01:03:46 UTC 2013


...

Andrew Fried wrote:
> 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. 

i agree about spamhaus and surbl. i note that threatstop also has an rpz
service, constantly updated in real time. subscribers should evaluate
all of them and then keep whichever set works best. note that the
performance problems from subscribing to more than one rpz have been
solved, patches for fast-rpz are included in the rrl work (see
http://www.redbarn.org/dns/ratelimits). also, i've asked dns-oarc if
they'd be willing to host a copy of the rpz specification and a list of
self-described rpz reputation publishers (that is, we won't verify
claims or make recommendations on such a page.)

> The kind of data that goes into an rpz could vary based on an end user's
> need, but generally you'd want malware sites, phishing sites, cracked
> sites and known criminal spam sites blocked.  Policy type lists would
> add specialized type data such as porn, gambling, pharma, replica watch
> sales and the likes.

what tom was trying to describe is that all of those options are
checkboxes in a per-subscriber rpz build machine. rather than export
multiple lists and let a subscriber pick several lists, the subscriber
logs into a portal and asks threatstop to build them an rpz having only
certain elements. i expect that this was more important before fast-rpz
solved the multiple rpz performance problems, but it's still quite cool.

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

indeed, the use cases for a dns whitelist are going to be extremely rare.

paul




More information about the DNSfirewalls mailing list