[RPZ] "DNS Firewalls In Action - RPZ vs. Spam" (circleid)

Paul Vixie paul at redbarn.org
Sun Jan 6 02:39:42 UTC 2013

Andrew Fried wrote:
> ...
> RPZ can incrementally replicate changes to it's slaves in a matter of
> seconds, whereas rsync'ed files take longer, consumes more bandwidth
> and take longer to import since the entire zone needs to be read in
> during each update.  In short, RPZ is faster, easier to replicate and
> pretty much foolproof so long as your rpz data is good.  Think in
> terms of replicating regenerated rpz zone files every 1-3 minutes to
> hundreds of customers; then try and do that via rsync.

if you use rfc 2136 style updates to insert and delete rules in an rpz,
and if you tune your master server aggressively, you can get small
updates propagated to hundreds of hosts every few seconds. this has two
nice properties, one is that total propagation delay from the moment you
learn that some domain is evil until all of your rpz's subscribers are
blocking that domain, is a matter of seconds. the other benefit is, the
bandwidth utilization is neatly spread across time, there's no big
transfer happening.

> The biggest challenge I've seen in providing rpz services is that
> potential customers are either unable or unwilling to hand configure a
> current version of bind on their recursive nameservers.  Without that,
> rpz isn't possible.  I suppose once the *nix distro's finally start
> providing current versions of bind in their distro's that problem will
> go away.  For something like RedHat, that could take another decade,
> since RedHat seems to make it an art-form of using old, back-ported
> software.

i suggest that you start by talking to the fedora team, who is more apt
to ship current software, which is in turn likely to cause RH customers
to notice the features missing in RHEL. RH is an exquisitly customer
driven company.


More information about the DNSfirewalls mailing list