<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Andy<br>
<br>
<br>
On 1/5/13 4:16 PM, April Lorenzen wrote:<br>
<blockquote type="cite">On 1/5/13 2:47 PM, Paul Vixie wrote:<br>
<br>
<br>
> April Lorenzen wrote:<br>
>> ...<br>
>><br>
>> I would have liked to respond to your question of whether
more zones causes rpz enabled bind to slow down more but I<br>
>> eventually realized I don't have the kind of query volume
that would show any change in performance.<br>
<br>
> so, you're using rpz as part of your commercial service, as
in, on the authority side?<br>
<br>
The customer queries my recursive RPZ-feature-enabled resolver so
I am not understanding how that is the authority side. What I<br>
expect you wouldn't have intended is RPZ-bind as a domain BL where
answers other than 127.0.0.2 are ignored by the customer and<br>
they are just querying it for a thumbs up or down reputation
answer.<br>
<br>
My service certainly could be used for low to medium volume users
as their recursive resolver - these are just dedicated Amazon or<br>
other brand virtual machines. I am not intending to enter the area
of providing recursive resolver service - it just does happen<br>
to function that way if someone wants to use it that way for
testing or whatever purpose.<br>
<br>
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<br>
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<br>
resolver they use, or certain RPZ features being still
experimental prevents them from getting bind built with those
compile<br>
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<br>
on ec2 or Rackspace vm.<br>
<br>
The RPZone.us slave(s) are dedicated just to that service, they
don't aggregate or combine any other services. I have a large<br>
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<br>
queries a month.<br>
<br>
The medium mail systems that use my similar lists for inbound
(postfix and a custom implementation) are still rsyncing static<br>
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<br>
denying miscreants their time window of operation.<br>
<br>
- April Lorenzen<br>
<a class="moz-txt-link-freetext" href="https://service.dissectcyber.com">https://service.dissectcyber.com</a><br>
<br>
> also note, vernon has been working on rpz performance. i'm
expecting new patches momentarily; release notes to come.<br>
<br>
> paul<br>
<br>
<br>
</blockquote>
<span style="white-space: pre;">>
_______________________________________________<br>
> dnsrpz-interest mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:dnsrpz-interest@lists.isc.org">dnsrpz-interest@lists.isc.org</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dnsrpz-interest">https://lists.isc.org/mailman/listinfo/dnsrpz-interest</a></span><br>
<br>
-- <br>
Andrew Fried<br>
Internet Systems Consortium, Inc.<br>
<a class="moz-txt-link-abbreviated" href="mailto:afried@isc.org">afried@isc.org</a><br>
+1.650.423.1343<br>
<br>
</body>
</html>