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.
