Yesterday I rebooted a Debian Lenny system for the first time since
applying the upgrade to Lenny a few months ago, and about 5 minutes
later Dnsmasq stopped responding to DNS queries (local or LAN).
Restarting Dnsmasq didn't help. No queries would show up in the log from
that point forward. A reboot would restore operation for a little while,
but then it would break again.
I explored a whole bunch of potential causes, but the culprit turned up
when I took a closer look at netstat:
# netstat -anp | fgrep dns
tcp 0 0 192.168.0.35:53 0.0.0.0:* LISTEN
6348/dnsmasq
udp 0 0 192.168.0.35:53 0.0.0.0:*
6348/dnsmasq
udp 111356 0 192.168.0.35:53 0.0.0.0:*
4969/dnscache
udp 0 0 127.0.0.10:53 0.0.0.0:*
2987/tinydns
udp 0 0 0.0.0.0:67 0.0.0.0:* 6348/dnsmasq
The Lenny upgrade apparently resurrected a dormant (and now completely
removed) installation of djbdns (dnscache, tinydns).
I think this set up a situation similar to what was described in this
bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310772
talking about how bind9, if configured to listen on all IPv4 and IPv6
addresses can block, if it receives a UDP packet on "an IPv4 address on
which bind9 is NOT listening."
The symptoms described are identical to what I observed. As if an OS
buffer for the UDP packets filled up, and from that point forward,
things didn't work.
(The above netstat output reflects some changes I made to Dnsmasq's
settings to get it to listen specifically on the LAN IP address, in an
attempt to resolve the problem, but it didn't work. I had been running
with the default (unset) settings. I did find that setting
bind-interfaces in addition to listen-address fixed the problem, prior
to finding the true case, but with djbdns removed, I've reverted back to
the default settings.)
I'm wondering of Dnsmasq could be enhanced to detect this kind of a
conflict, and issue a warning?
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
