Possible memory leak on BIND 9.10.1-P1 running on FreeBSD 10.1-RELEASE-p4 - part 2

2015-01-26 Thread Daniel Ryšlink
Downgraded to BIND 9.9.6, the leak is gone, using the same named.conf, same HW, same environment. It is highly likely there is really a memory leak problem in Bind 9.10. -- S pozdravem, Daniel Ryšlink System Administrator Dial Telecom a. s. Křižíkova 36a/237 186 00 Praha 3, Česká Republika

BIND response time is relatively high

2015-01-26 Thread alaa m zidan
hi , I noticed that at peak hours, BIND response time is relatively high for some servers.non-cached query takes over 700msI set some kernel parameters to tune the network and sockets for redhat 6 and set some global options to tune the BIND by modifying the cache settings, but neither I get

Re: Possible memory leak on BIND 9.10.1-P1 running on FreeBSD 10.1-RELEASE-p4 - part 2

2015-01-26 Thread Mukund Sivaraman
Hi Daniel On Mon, Jan 26, 2015 at 02:56:44PM +0100, Daniel Ryšlink wrote: Downgraded to BIND 9.9.6, the leak is gone, using the same named.conf, same HW, same environment. It is highly likely there is really a memory leak problem in Bind 9.10. Because many of these reports are on FreeBSD

is this normal if not what to do about it?

2015-01-26 Thread John
my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the ZSK the inactive date-time is a few hours different, but in the ZSKs case it is 3 months. Is this a

Re: is this normal if not what to do about it?

2015-01-26 Thread John
oops!! I swapped the ZSK and KSK in the table. On January 26, 2015 9:09:40 PM John j...@klam.ca wrote: my experimental zone (the family site) klam.ca has a KSK and a ZSK. There appear to be time differences between the records reported by DIG and the source records on file. In the case of the

Re: BIND response time is relatively high

2015-01-26 Thread Niall O'Reilly
At Mon, 26 Jan 2015 21:50:37 +, Darcy Kevin (FCA) wrote: The parameter that is glaringly missing from your list is “recursive-clients”. Do you have that set at default value (1000) or have you bumped it up higher? Since you say that this happens at “peak hours”, recursive-clients is