[Dnsmasq-discuss] forwarding table overflow

[Simon Kelley]

Davide Ferrari wrote:
> In the last days I've experienced a few errors with dnsmasq, that leave this 
> trace in the log
> 
> Nov 30 15:43:59 fw2 dnsmasq[27761]: forwarding table overflow: check for 
> server loops.
> 
> what does this mean? when this happens, hosts behind dnsmasq cannot resolve 
> names...but this seems to solve by itself in a few seconds. What's happening?
> 

This is a sort-of-FAQ, but it's worth getting an explanation in one
place which is up to date, as things have changed recently.

The "forwarding table" is a data structure used to keep track of DNS
queries which get forwarded to upstream nameservers. Each time dnsmasq
gets a DNS query which it cannot answer, it puts some information about
the query into the forwarding table, and then send the query on to an
upstream nameserver. When the reply comes back, the data is sent to the
original requestor, and the table entry is freed. If an answer is not
recieved for 20 seconds, the table entry is also freed.

The table is limited in size, otherwise is would be possible for an
attacker to make dnsmasq use lots of memory by flooding it with DNS
queries. The default size if 150 queries. Before version 2.33, this was
changable only be re-compiling. From version 2.33 the --dns-forward-max
option can set it a run-time.

If dnsmasq receives a query and the table is full, then it logs the
"table full" message and fails the query. This is normally caused by
queries arriving at a high rate, or slow or unreliable upstream
nameservers. The classic way to provoke the problem is to use one of the
utilities which parse server log files and make bulk DNS queries to
re-write all the IP addresses as hostnames.

This behaviour changed in version 2.34, The "table full" message has
gone. Now, when the  table is full, dnsmasq stops accepting new queries;
allowing them to be queued by the kernel instead. When the overload
clears, the queries are handled. This change gives better behaviour for
transient overloads, like you are seeing. (Instead of failed queries,
there will be a short delay.) It doesn't handle gross overloads so well.
(There will be no errors logged: eventually the kernel queues will fill
and queries will be silently dropped.)


HTH


Simon.