<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
On Fri, 2013-09-20 at 14:12 +0000, Vernon Schryver wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
> From: Shane Kerr <<A HREF="mailto:shane@isc.org">shane@isc.org</A>>
> With a 50% packet loss and 3 retries you'll have about 1 in 16 lookups
> fail, right? If you've got enough legitimate lookups going on to
> trigger RRL then you're going to get lots of failures.
If 6% is "lots", then yes.
</PRE>
</BLOCKQUOTE>
<BR>
it certainly is, I accept 1% error margins, anything more, then its too high.<BR>
If I was still managing public ISP DNS, then 0.01% error margin would be even a bit high, but then again, their I wouldnt be running views <IMG SRC="cid:1379818961.5593.6.camel@tardis" ALIGN="middle" ALT=":)" BORDER="0"><BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
> > limit NXDOMAIN responses to xxxxxxxx/24 for zen.spamhaus.org ,=20
> This doesn't indicate that anything actually failing for the querying
> hosts, just that they are issuing a lot of queries.
indeed.
</PRE>
</BLOCKQUOTE>
<BR>
but the end result was, that RRL filtering was filytering, as per my other message, however, ns0 is now using RRL in a view and has thus far (just over 24 hours) not given us any problems, NS 1 and 2 have always been pure authoritative, so never effected.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
The potential RRL problem is when you provide high volume DNSBL service
</PRE>
</BLOCKQUOTE>
<BR>
that problem is removed now since the internal view for caching wont be filtered when querying them, and our internal dnsbl has never needed to be RL'd since although public access is allowed, its volume is too low to be measurable compared to the well known ones <IMG SRC="cid:1379818961.5593.6.camel@tardis" ALIGN="middle" ALT=":)" BORDER="0"><BR>
<BR>
Thanks for clearing up hte options, seems it should all be good now.<BR>
<BR>
<BR>
</BODY>
</HTML>