[Dnsmasq-discuss] multiple programs using UDP port 53

Tom Metro tmetro+dnsmasq at gmail.com
Fri Jul 3 22:13:28 BST 2009

Simon Kelley wrote:
> Tom Metro wrote:
>> # netstat -anp | fgrep dns
>> tcp        0  0*     LISTEN 6348/dnsmasq
>> udp        0  0* 6348/dnsmasq
>> udp   111356  0* 4969/dnscache
>> udp        0  0* 2987/tinydns
>> udp        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*     LISTEN    16281/dnsmasq
tcp6   0   0 :::53         :::*          LISTEN    16281/dnsmasq
udp    0   0*               16281/dnsmasq
udp    0   0*               16281/dnsmasq
udp6   0   0 :::53         :::*                    16281/dnsmasq

With listen-address:

# netstat -anp | fgrep dns
tcp    0   0*     LISTEN    1862/dnsmasq
tcp6   0   0 :::53         :::*          LISTEN    1862/dnsmasq
udp    0   0*               1862/dnsmasq
udp    0   0*               1862/dnsmasq
udp6   0   0 :::53         :::*                    1862/dnsmasq

With listen-address and bind-interfaces:

# netstat -anp | fgrep dns
tcp    0   0*   LISTEN    2062/dnsmasq
udp    0   0*             2062/dnsmasq
udp    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

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
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 Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/

More information about the Dnsmasq-discuss mailing list