Q on clients-per-query, max-clients-per-query

[Mark Andrews]

In message <60834.75625.qm at web121403.mail.ne1.yahoo.com>, Fr34k writes:
> Hello,
> 
> # The ARM says: #
> clients-per-query, max-clients-per-query
> These set the initial value (minimum) and maximum number of recursive 
> simultaneous clients for any given query (<qname,qtype,qclass>) that the serv
> er 
> will accept before dropping additional clients. named will attempt to self tu
> ne 
> this value and changes will be logged.  The default values are 10 and 100.
> 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 i
> s 
> set to zero, then there is no upper bound other than imposed by 
> recursive-clients.
> 
> 
> # Consider that I have: #
> clients-per-query 10 ; max-clients-per-query 20 ;
> 
> 
> # What I think this means in hypothetical situations: #
> 1.  If I have 100 customer Windows machines requesting A record(s) for 
> non-responsive-domain.com, then my caching server will only recurs the first 
> 20 
> of such requests and drop the other 80.  Is this correct, or what is the like
> ly 
> process?
> 
> 2.  If I have 100 customer Windows machines requesting A record(s) for 
> very-slow-to-respond.com, then my caching server will only recurs  the first 
> 20 
> of such requests and drop the other 80.  Is this correct, or what is the like
> ly 
> process?
> 
> Let's say the name servers authoritative for this domain finally respond, the
> n 
> my bind server will respond to the 20 queries.
> Is this correct, or what is the likely process?
> 
> Now that I have the A record for www.very-slow-to-respond.com in cache (say T
> TL 
> is 24h) and it is likely that the 80 unsatisfied customer Windows machines wi
> ll 
> make another query attempt and, because I have this cached, finally get a 
> response.
> Is this correct, or what is the likely process?
> 
> It won't hurt my feeling if someone rather provide a better example that may 
> demonstrate how these settings work.

You have a empty cache.  You get a query for google.com.  You send
a query to the root servers for google.com.  Another query for
google.com comes in.  You add it to the existing query for google.com.
You get the answer back from the root servers.  You ask the com
servers for google.com.  You get another 3 query for google.com,
you add these to the original query.  You get a response from the
com servers. You ask the google.com servers for google.com.  You
get more queries for google.com.  You get a answer back from the
google.com servers and you send the answers back to all the clients
that asked you for google.com.  Future queries for google.com will
be answered from the cache until the record expires.

Now if more than 10 clients ask you for google.com while this is
happening you will just drop the new clients (they should retry).
Named will remember that it dropped clients and as it got a answer
it will increase the number of clients that it serve for the next
query.  It's a little more complicted than this but this will do
for this explaination. This lets named adjust to the normal query
rate and how far it is from the usual nameservers it talks to round
trip wise.  This normally take less than a second.

Now lets say the servers for a zone are unreachable.  Named will
only queue up 10 clients before it starts dropping them.  This stops
the recursive client slots all being taken on queries talking to
these servers.

Similar a flash crowd of queries for the same name will be mostly
dropped until the answer is received.

Mark

> Thank you.
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org