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 <[EMAIL PROTECTED]>
>>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 (<qname,qtype,qclass>) 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
