New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)

[Noel Butler]

Hi Vernon,
On Thu, 2013-09-19 at 23:42 +0000, Vernon Schryver wrote:


> BIND RRL has had whitelisting for trusted DNS clients that send repeated
> DNS requests since early days, long before any version of BIND 9.9.4.
> Look for 'exempt-clients{address_match_list};' in either the ARM that
> comes with 9.9.4 or via the old link labeled "Draft text for BIND9
> Administrators Reference Manual (ARM) describing DNS Response Rate
> Limiting (RRL)" on the original ratelimits web page at
> http://www.redbarn.org/dns/ratelimits
> 
>     [ rate-limit {
> 	...
> 	[ exempt-clients  { address_match_list } ; ]
> 	...
>       } ; ]
> 
>  ...
> 
>   DNS clients within a view can be exempted from rate limits with
>   the exempt-clients clause.
> 
> 

Thanks for the pointers, I see what I need to do now.


> RRL is not recommend for recursive DNS servers, because in theory
> it could squelch repeated requests from legitimate DNS clients
> without caches such as some SMTP servers.
> 


As per my previous to Evan, dealing with views, I'm on redbarn reading
now, I never ran it as patches, my policy is only use official upstream
sources, so my first play around was with 9.9.3.b2 I think it was.


> However, I do not recall reports of significant real, as opposed to
> anticipated or minor problems with RRL on recursive DNS servers.  The
> worst that should happen is that legitimate clients will be slowed,
> such as SMTP servers (mail receivers) receiving spews of spam or SMTP
> clients (mail senders) spewing spam or without required DNSBL whitelisting.
> A legitimate DNS client that is squelched by RRL will time-out every
> other repeated request and (with the default SLIP=2) retry with TCP.
> 
> What problems did you see with your mail system and your recursive DNS
> server with RRL?
> 


plenty of delayed mail -  hostname lookup failures (mostly because of
URI/DNS BL's), so it certainly works as intended :)
I will play around with views here over next day or so, from previous
plays, it did not take long to see the undesired results, so if its all
good I'll commit it to the serves I look after
(I did not see any issues on ns1/2, only ns0 which is split views,
authoritative and cache) 

Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130920/bb5347c9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-smile.png
Type: image/png
Size: 873 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130920/bb5347c9/attachment.png>
-------------- 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/bb5347c9/attachment.bin>