RRL probably not useful for DNS IP blacklists, was Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)

Noel Butler noel.butler at ausics.net
Fri Sep 20 10:02:26 UTC 2013


Hi Shane,

On Fri, 2013-09-20 at 11:38 +0200, Shane Kerr wrote:
> Noel,
> 
> On 2013-09-20 12:48:31 (Friday)
> Noel Butler <noel.butler at ausics.net> wrote:
> 
> > On Fri, 2013-09-20 at 01:59 +0000, Vernon Schryver wrote:
> 
> > > > plenty of delayed mail -  hostname lookup failures (mostly because of
> > > > URI/DNS BL's), so it certainly works as intended :)
> > > 
> > > That sounds unrelated to RRL.  Again, RRL affects standards compliant
> > > DNS clients no more than a 50% packet loss rate on the path from the
> > > DNS client and to the server.  If your mail system suffered hostname
> > > lookup failures, then I think something else was broken.
> 
> 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.
> 
> One workaround for this is to set SLIP to 1. I know Vernon recommends
> against that, but personally I don't think there is any downside.
>  

Might give that a go, thanks for suggestion

> > Nope, either way, daemon.log was filling up with messages indicating
> > RRL, last time I tried, Aug 29,
> > 
> > lots of  
> > limit NXDOMAIN responses to xxxxxxxx/24 for zen.spamhaus.org , 
> > limit NXDOMAIN responses to xxxxxx/24 for xxx.net 
> > 
> > pretty much one for every DNSBL, URIBL etc used.... 
> 
> This doesn't indicate that anything actually failing for the querying
> hosts, just that they are issuing a lot of queries.
> 

maybe not directly, but along with time corresponding maillog filling up
with errors certainly is all the proof I need.

> > The problem occurred within a minute of enabling RRL, and ended right
> > after disabling RRL.
> > on that date, log files show the version was actually BIND 9.9.4rc1
> > 
> > Now I've read your link, I can perhaps understand more the options and
> > fine tune it, but bout to head out for lunch so, might pla around later
> > this afternoon.
> 
> I think the actual issue is that for DNS IP blacklists (or whitelists)
> RRL is probably harmful. Many or even most queries to those servers
> will result in the same NXDOMAIN response. This is expected and desired
> behavior, but RRL interprets this as potential abuse.
> 
> While the fallback to TCP (combined with my recommendation of SLIP 1
> above) will mean that service will continue without problem, one reason
> that DNS was chosen for such services is that it is very lightweight,
> and forcing traffic to TCP is an anti-goal. :)
> 
> Probably you should disable RRL for servers that are primarily used for
> IP-based blacklists (or whitelists).
> 

Will try with views and SLIP 1, likely tomorrow now since its rather
late here, will post a followup with results

Cheers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130920/0f65d3bc/attachment.bin>


More information about the bind-users mailing list