Re: Q on clients-per-query, max-clients-per-query
- 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 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. So, does BIND behave the same whether it is a single PC making 100 queries for 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. 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
Re: Q on clients-per-query, max-clients-per-query
So, does BIND behave the same whether it is a single PC making 100 queries for 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) Differently. There is also code that drops duplicate queries, although 'duplicate' is based on more than just the client IP address and the query name/type. I'm using 9.7.2-P2, if version is significant. It is. If you're having problems related to your tuning questions, then we'd recommend upgrading to the current 9.7 version 9.7.3 which contains the following bug fix for a specific corner case: 3009. [bug] clients-per-query code didn't work as expected with particular query patterns. [RT #22972] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Q on clients-per-query, max-clients-per-query
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
Q on clients-per-query, max-clients-per-query
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 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. 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. # 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 likely 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 likely process? Let's say the name servers authoritative for this domain finally respond, then 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 TTL is 24h) and it is likely that the 80 unsatisfied customer Windows machines will 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. Thank you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Q on clients-per-query, max-clients-per-query
In message 60834.75625...@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@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
