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

Marcelo Salhab Brogliato msbrogli at vialink.com.br
Fri May 31 12:51:09 BST 2013


Thanks to you, Simon. Dnsmasq is a very good piece of software. :)

Cheers,

-- msbrogli

On May 31, 2013, at 07:51 , Simon Kelley <simon at thekelleys.org.uk> wrote:

> On 30/05/13 23:16, Marcelo Salhab Brogliato wrote:
>> 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.
> 
> That makes perfect sense.
> 
>> 
>> Totally agree with rate limit in log messages. I'll take a look into
>> the code and try to do it.
> 
> It turns out to be very simple. Your patch, with rate limiting added, is in the git repo now.
> 
> Many thanks.
> 
> Cheers,
> 
> Simon.
> 
> 
>> 
>> 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
>> 
>> 
> 




More information about the Dnsmasq-discuss mailing list