Simon Kelley wrote:
Tom Metro wrote:
# 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 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.)
That netstat output makes it look like "bind-interfaces" is set in
dnsmasq, was that the case?
I'm not absolutely positive, as I plucked that screen capture from a
terminal history after the fact, but I'm pretty sure that it represents
a point in time when bind-interfaces was unset, but listen-address was set.
I can easily enough repeat the conditions with the exception of running
djbdns. So here's the netstat with the default (and current) settings:
# netstat -anp | fgrep dns
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 16281/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 16281/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 16281/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 16281/dnsmasq
udp6 0 0 :::53 :::* 16281/dnsmasq
With listen-address:
# netstat -anp | fgrep dns
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1862/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 1862/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 1862/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 1862/dnsmasq
udp6 0 0 :::53 :::* 1862/dnsmasq
With listen-address and bind-interfaces:
# netstat -anp | fgrep dns
tcp 0 0 192.168.0.35:53 0.0.0.0:* LISTEN 2062/dnsmasq
udp 0 0 192.168.0.35:53 0.0.0.0:* 2062/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 2062/dnsmasq
This would seem to confirm your suspicion that bind-interfaces was in
effect when that netstat was captured.
Do you still see the problem without "bind-interfaces" and with
dnsmasq bdound to 0.0.0.0:53?
No, once the other DNS server was killed off, Dnsmasq worked normally.
As I noted, I reverted to the original default Dnsmasq settings once I
located the source of the problem.
Is there a known reason why dnscache would not be reading arriving
packets, thus eventually filling the kernel buffers associated with the
socket?
Unknown. dnscache hasn't been used in several years. I could speculate
that there may have been a problem with its logging, seeing as it uses
its own logging system, but really it could have been anything, like a
missing config file. I just checked the logs for it, which seem to have
been functioning, but I see the "supervise" process process never died
(and can't be killed, apparently - returns a "Operation not permitted"
to a TERM signal), so it has overwritten the logs with a repeated
message like:
softlimit: fatal: unable to run /usr/bin/dnscache: file does not exist
and:
softlimit: fatal: unable to run /usr/bin/tinydns: file does not exist
So unfortunately the original cause is lost.
I take it the system calls permit more than one process to bind to a UDP
port? If so, then what determines which process gets the packets?
If you don't get direct feedback of the problem from the system calls,
then I guess detecting this situation would require adding code to
specifically look for it, would would probably be messy and fragile.
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
