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

Andrew Fried afried at isc.org
Sun Jan 6 01:53:29 UTC 2013

Using a list via rbldnsd works well for a mail dbl.  Using the same data
in an rpz aware dns server provides coverage for both mail and general
Internet traffic.

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.

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


On 1/5/13 4:16 PM, April Lorenzen wrote:
> On 1/5/13 2:47 PM, Paul Vixie wrote:
> > April Lorenzen wrote:
> >> ...
> >>
> >> I would have liked to respond to your question of whether more
> zones causes rpz enabled bind to slow down more but I
> >> eventually realized I don't have the kind of query volume that
> would show any change in performance.
> > so, you're using rpz as part of your commercial service, as in, on
> the authority side?
> The customer queries my recursive RPZ-feature-enabled resolver so I am
> not understanding how that is the authority side. What I
> expect you wouldn't have intended is RPZ-bind as a domain BL where
> answers other than are ignored by the customer and
> they are just querying it for a thumbs up or down reputation answer.
> My service certainly could be used for low to medium volume users as
> their recursive resolver - these are just dedicated Amazon or
> other brand virtual machines. I am not intending to enter the area of
> providing recursive resolver service - it just does happen
> to function that way if someone wants to use it that way for testing
> or whatever purpose.
> I think it is great when people use an RPZ capable resolver as their
> recursive resolver - yet that isn't as easy for some users at
> this time as it is to use it like a domain BL. They are using some
> other resolver brand, they don't control what recursive
> resolver they use, or certain RPZ features being still experimental
> prevents them from getting bind built with those compile
> options for their production servers. So in the meantime I can offer
> it for them to use as a domain BL or try, with me running it
> on ec2 or Rackspace vm.
> The RPZone.us slave(s) are dedicated just to that service, they don't
> aggregate or combine any other services. I have a large
> company using it for outbound and smaller mail systems so far using it
> for inbound. Entry level of $10/mo for about 2.6 million
> queries a month.
> The medium mail systems that use my similar lists for inbound (postfix
> and a custom implementation) are still rsyncing static
> lists which I want to get away from. I prefer the whole concept of RPZ
> and the immediacy of changes to the zones, thus potentially
> denying miscreants their time window of operation.
> - April Lorenzen
> https://service.dissectcyber.com
> > also note, vernon has been working on rpz performance. i'm expecting
> new patches momentarily; release notes to come.
> > paul
> _______________________________________________
> dnsrpz-interest mailing list
> dnsrpz-interest at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dnsrpz-interest

Andrew Fried
Internet Systems Consortium, Inc.
afried at isc.org

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

More information about the DNSfirewalls mailing list