[Dnsmasq-discuss] Warning when maximum number of concurrent DNS queries is reached

[Marcelo Salhab Brogliato]

Simon,

The default value for maximum number of forward is 150 and the servers was receiving much more than that (I guess it was between 200 and 300 requests). Thus, many requests were very slow (probably due to a long queue) and some were expiring time limit. Changing the limit to 500 forwards fixed my problem. So, I guess some logging would improve the time I took to diagnose and fix it.

Totally agree with rate limit in log messages. I'll take a look into the code and try to do it.

Cheers,

-- msbrogli

On May 30, 2013, at 06:29 , Simon Kelley <simon at thekelleys.org.uk> wrote:

> On 30/05/13 01:41, Marcelo Salhab Brogliato wrote:
>> Dear,
>> 
>> Today I had a problem on my DNS server because it reached the maximum number of concurrent DNS queries. It was "hard" to discover the cause of the problem because there is no log that it have happened. I took a look at the code and this log is really missing and I guess it is very important.
>> 
>> Follow my suggestion of improvement for problem detection purpose.
>> 
>> Version: 2.52
>> Patch:
>> --- forward.c.original	2013-05-29 21:34:13.836999570 -0300
>> +++ forward.c	2013-05-29 21:34:22.837164945 -0300
>> @@ -1007,6 +1007,7 @@
>>      {
>>        if (oldest&&  wait)
>>  	*wait = oldest->time + (time_t)TIMEOUT - now;
>> +      my_syslog(LOG_WARNING, _("Maximum number of concurrent DNS queries reached (max: %d)"), daemon->ftabsize);
>>        return NULL;
>>      }
>> 
>> What do you think about it?
>> 
> 
> It's many years since this was last looked at.
> 
> This code used to to log an error and drop the query. The logging was removed when it was changed to not accept new queries when the forwarding table is full. The idea is that the UDP packets are queued in the kernel until resources become available.
> 
> I'm interested to know about the problem you had: this is supposed to be handled without drama.
> 
> I'm happy in principle to add logging, but some rate-limiting may be required. Note that get_new_frec() is called for two purposes: from the forwarding path to actually allocate a record, and from the select() loop, where it just discovers is the table is full or not, and calculates how long it will be until space is available. The second could be responsible for a lot of calls and a lot of log messages.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20130530/95e4be49/attachment.html>