[Dnsmasq-discuss] multiple programs using UDP port 53

[Tom Metro]

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/