Hi,

is there really none that can explain why clients-per-query get so high even though
max-clients-per-query = 100.... ?

Thanks
Jan Arild Lindstrom


At 08:01 09/09/2008, Jan Arild LindstrÝm wrote:

>Hi,
>
>I can not see how that will do any difference, since the the number is way bigger than
>max-clients-per-query limit 70 or 100:
>
> ns(root) named 536# rndc recursing ; cat named.recursing | awk '{print $6}' | sort | uniq -c | sort -n | tail -5
> 809 'crl.verisign.net'
> 826 'apps.facebook.com'
> 2503 'ocsp.verisign.net'
> 12850 'www.facebook.com'
> 20064 'statistik-gallup.net'
>
>It seems on my that the limit is not working as I think it should. Have I understood the way
>the limit should work, or is there something faulty in the code that should limit clients-per-query?
>
>Regards
>Jan Arild Linsdtrom
>
>
>At 18:13 08/09/2008, Fr34k wrote:
>>Hello,
>>
>>"07-Sep-2008 19:47:14.187 resolver: clients-per-query increased to 70"
>>
>>70 clients per query seems pretty high to me.
>>I think slow, and bogus, lookups can contribute to this.
>>
>>In our environment, we use:
>> clients-per-query 10 ;
>> max-clients-per-query 20 ;
>>
>>I would also check that the network is clean: no interface errors on server or switch, etc.
>>
>>There may also be bots, and such, driving up DNS traffic in attempts to propagate abuse.
>>Typically, hundreds of MX lookups from DHCP workstations indicate such malware infections.
>>Once upon a time, someone pointed me to a Surf net document on using DNS as IDS -- which has some other great ideas.
>>Anyway, the goal is innoculating infected hosts to stop bogus traffic.
>>
>>I hope this helps.
>>
>>
>>
>>----- Original Message ----
>>From: Jan Arild LindstrÝm
>>To: bind-users@isc.org
>>Sent: Monday, September 8, 2008 6:38:58 AM
>>Subject: BIND 9.4.x and max-clients-per-query
>>
>>
>>Hi,
>>
>>we got serveral recursive BIND 9.4.x servers running with the following option set
>>in named.conf:
>> recursive-clients 50000;
>>
>> From named.log yesterday @ 19:44 ->
>>
>>--CUT--
>>07-Sep-2008 19:44:01.250 resolver: clients-per-query increased to 70
>>07-Sep-2008 19:44:03.124 resolver: clients-per-query increased to 75
>>07-Sep-2008 19:44:49.700 general: dispatch.c:2999: INSIST(n == 1) failed
>>07-Sep-2008 19:44:49.700 general: exiting (due to assertion failure)
>>07-Sep-2008 19:44:53.939 general: zone 0.0.127.in-addr.arpa/IN/internal: loaded serial 1
>>07-Sep-2008 19:44:53.948 general: zone localhost/IN/internal: loaded serial 1
>>07-Sep-2008 19:44:55.109 general: zone 0.0.127.in-addr.arpa/IN/external: loaded serial 1
>>07-Sep-2008 19:44:55.113 general: zone localhost/IN/external: loaded serial 1
>>07-Sep-2008 19:44:56.282 general: running
>>07-Sep-2008 19:44:56.961 resolver: clients-per-query increased to 15
>>07-Sep-2008 19:44:58.127 resolver: clients-per-query increased to 20
>>07-Sep-2008 19:45:00.168 resolver: clients-per-query increased to 25
>>07-Sep-2008 19:45:01.602 resolver: clients-per-query increased to 30
>>07-Sep-2008 19:45:04.079 resolver: clients-per-query increased to 35
>>07-Sep-2008 19:45:09.490 resolver: clients-per-query increased to 40
>>07-Sep-2008 19:45:11.826 resolver: clients-per-query increased to 45
>>07-Sep-2008 19:45:14.200 resolver: clients-per-query increased to 50
>>07-Sep-2008 19:45:21.336 resolver: clients-per-query increased to 55
>>07-Sep-2008 19:45:29.406 resolver: clients-per-query increased to 60
>>07-Sep-2008 19:46:05.896 resolver: clients-per-query increased to 65
>>07-Sep-2008 19:47:14.187 resolver: clients-per-query increased to 70
>>07-Sep-2008 19:49:28.621 client: client xx.xx.xx.xx#59739: view external: recursive-clients soft limit exceeded, aborting oldest query
>>07-Sep-2008 19:49:29.258 client: client xx.xx.xx.xx#1025: view external: recursive-clients soft limit exceeded, aborting oldest query
>>07-Sep-2008 19:49:30.043 client: client xx.xx.xx.xx#64760: view external: recursive-clients soft limit exceeded, aborting oldest query
>>07-Sep-2008 19:49:31.012 client: client xx.xx.xx.xx#38850: view external: recursive-clients soft limit exceeded, aborting oldest query
>>--CUT--
>>
>>clients-per-query, max-clients-per-query
>> These set the initial value (minimum) and maximum number of recursive simultanious clients for
>> any given query () that the server will accept before dropping additional
>> clients. named will attempt to self tune this value and changes will be logged. The default values
>> are 10 and 100.
>>
>> This value should reflect how many queries come in for a given name in the time it takes to resolve
>> that name. If the number of queries exceed this value, named will assume that it is dealing with a
>> non-responsive zone and will drop additional queries. If it gets a response after dropping queries, it
>> will raise the estimate. The estimate will then be lowered in 20 minutes if it has remained unchanged.
>>
>> If clients-per-query is set to zero, then there is no limit on the number of clients per query and no
>> queries will be dropped.
>>
>> If max-clients-per-query is set to zero, then there is no upper bound other than imposed by recursive-clients.
>>
>>While the recursive queue was filling, I checked the recursive queries:
>> ns(root) named 536# rndc recursing ; cat named.recursing | awk '{print $6}' | sort | uniq -c | sort -n | tail -5
>> 809 'crl.verisign.net'
>> 826 'apps.facebook.com'
>> 2503 'ocsp.verisign.net'
>> 12850 'www.facebook.com'
>> 20064 'statistik-gallup.net'
>>
>> rndc status:
>> recursive clients: 49662/49900/50000
>>
>>Clients-per-query and max-clients-per-query are not set, so they are at default 10 and 100.
>>
>>How is it that these queries have so many simultanious clients? Should not max-clients-per-query keep
>>it to max 100 simultanious clients for each query? All these numbers are way bigger than 100.
>>
>>Or have I not understood the purpose of clients-per-query and max-clients-per-query correctly?
>>
>>Thanks
>>Jan Arild Lindstrom