In message <688460.82562...@web121414.mail.ne1.yahoo.com>, Fr34k writes: > ----- Original Message ---- > > > From: Mark Andrews > > To: Fr34k > > Cc: Bindlist > > Sent: Wed, March 23, 2011 9:04:00 PM > > Subject: Re: Q on clients-per-query, max-clients-per-query > > > > > > In message <>, 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 se > lf > >tu > > > ne > > > this value and changes will be logged. The default values are 10 and 10 > 0. > > > If clients-per-query is set to zero, then there is no limit on the numbe > r of > > > > > clients per query and no queries will be dropped. If max-clients-per-qu > ery > >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 f > irst > > > > > 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 f > irst > > > > > 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 machin > es > >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. > > So, does BIND behave the same whether it is a single PC making 100 queries fo > r > the same record compared to 555 PCs making queries for the same record? > That is, how does BIND treat "clients-per-query, max-clients-per-query" > differently based upon the query requesters' IP address(es)? > > (I want to assume I know the answer, but I have an interesting network event > and > I want to be able to understand/communicate the snoop logs we captured) > > I'm using 9.7.2-P2, if version is significant. > > Thank you.
Named uses the source address, source port and query id to find duplicate queries. Duplicate queries are dropped before the clients-per-query code. A client is not a machine. It is a process/task on a machine. The code to find the existing query can fail to find it in the version of named you are running. This is fixed in 9.6.3, 9.7.3 and 9.8.0. 3009. [bug] clients-per-query code didn't work as expected with particular query patterns. [RT #22972] Mark > > Mark > > > > > Thank you. > > > > > > _______________________________________________ > > > bind-users mailing list > > > bind-users@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: > > > _______________________________________________ > bind-users mailing list > bind-users@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: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users