Discussion:
[Dnsmasq-discuss] dnsmasq listening on 0.0.0.0
Robert Diamond
2008-03-18 15:52:02 UTC
Permalink
I know that dnsmasq likes to do it's ip filtering in the user-space,
but I'd rather be able to specify ip's for it to bind to, that show up
in netstat. Maybe I'm just a little anal about that stuff, but it just
doesn't look right to me :) (Yahp, I've even added iptables rules in my
never ending effort to be crazy ^.~)

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q2/001322.html

Shows some options to get the dns server part binding to an ip via the
kernel. The dhcp server will still look like it's listening on all ip's
(as will the dns forwarder; and possibly tftp server?).

$ netstat -anlpA inet
<snip>
udp 0 0 127.0.0.1:53 0.0.0.0:* 30768/dnsmasq
udp 0 0 192.168.1.1:53 0.0.0.0:* 30768/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 30768/dnsmasq
udp 0 0 0.0.0.0:5353 0.0.0.0:* 30768/dnsmasq

[Internet interface ip]:5353 is where forwarded dns queries get sent
back to. I'd like "0.0.0.0:67" to show 192.168.1.1:67 and 0.0.0.0:5353
to show a.x.y.z:5353 (a.x.y.z being my internet/external ip). There was
a patch somewhere in this list, that has been added to the code a few
versions back that allowed multiple instances of dnsmasq to bind to
0.0.0.0. I'd just prefer if there was a 'listen-dns; listen-dnsforward;
listen-dhcp' (and maybe a 'listen-tftp') option that couples with
'bind-interface' to give my desired results.

I'm going to be doing some looking over the code in an effort to
include this functionality in a patch, but if someone else has done the
work already, or if I've somehow missed an available option in my conf
file please let me know :)
--
Robert A.M. Diamond
<***@gmail.com>
http://robshouse.no-ip.info

What if everything is an illusion and nothing exists? In that case, I
definitely overpaid for my carpet.
-- Woody Allen, "Without Feathers"
Simon Kelley
2008-03-18 17:10:37 UTC
Permalink
Post by Robert Diamond
I know that dnsmasq likes to do it's ip filtering in the user-space,
but I'd rather be able to specify ip's for it to bind to, that show up
in netstat. Maybe I'm just a little anal about that stuff, but it just
doesn't look right to me :) (Yahp, I've even added iptables rules in my
never ending effort to be crazy ^.~)
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q2/001322.html
Shows some options to get the dns server part binding to an ip via the
kernel. The dhcp server will still look like it's listening on all ip's
(as will the dns forwarder; and possibly tftp server?).
$ netstat -anlpA inet
<snip>
udp 0 0 127.0.0.1:53 0.0.0.0:* 30768/dnsmasq
udp 0 0 192.168.1.1:53 0.0.0.0:* 30768/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 30768/dnsmasq
udp 0 0 0.0.0.0:5353 0.0.0.0:* 30768/dnsmasq
[Internet interface ip]:5353 is where forwarded dns queries get sent
back to. I'd like "0.0.0.0:67" to show 192.168.1.1:67 and 0.0.0.0:5353
to show a.x.y.z:5353 (a.x.y.z being my internet/external ip). There was
a patch somewhere in this list, that has been added to the code a few
versions back that allowed multiple instances of dnsmasq to bind to
0.0.0.0. I'd just prefer if there was a 'listen-dns; listen-dnsforward;
listen-dhcp' (and maybe a 'listen-tftp') option that couples with
'bind-interface' to give my desired results.
I'm going to be doing some looking over the code in an effort to
include this functionality in a patch, but if someone else has done the
work already, or if I've somehow missed an available option in my conf
file please let me know :)
Splitting up the question:

DNS listening port - you've already solved that, with "bind-interfaces"
DNS upstream port - That's possible, if you specify the servers via a
"server=" line in /etc/dnsmasq.conf then you can specify the local
address (and port) too.

server=***@192.168.1.1#5353

tftp: "bind-interfaces" works for that too.

DHCP that always binds the wildcard - doing otherwise _may_ be possible,
but be prepared for much testing and strange behaviour. For instance,
you need to be able to receive packets whose destination address in
255.255.255.255.


Cheers,

Simon.
r***@gmail.com
2008-03-18 23:45:18 UTC
Permalink
Post by Simon Kelley
DHCP that always binds the wildcard - doing otherwise _may_ be possible,
but be prepared for much testing and strange behaviour. For instance,
you need to be able to receive packets whose destination address in
255.255.255.255.
But the DHCP socket is (or can be with a config file setting) bound to
a particular interface, even if not a particular IP, correct?
Post by Simon Kelley
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Simon Kelley
2008-03-19 16:24:14 UTC
Permalink
Post by r***@gmail.com
Post by Simon Kelley
DHCP that always binds the wildcard - doing otherwise _may_ be possible,
but be prepared for much testing and strange behaviour. For instance,
you need to be able to receive packets whose destination address in
255.255.255.255.
But the DHCP socket is (or can be with a config file setting) bound to
a particular interface, even if not a particular IP, correct?
At kernel level, it's not bound to anything. Dnsmasq sees DHCP packets
which arrive on all interfaces. The first thing it does is to filter
them based on --interface --except-interface and --no-dhcp-interface.
Anything which doesn't pass the filter is thrown away with no action.

The OP wants to be have the kernel do the filtering. There's no
practical benefit to doing that in most cases.

Cheers,

Simon.
Simon Kelley
2008-03-20 18:51:12 UTC
Permalink
Post by Simon Kelley
Post by r***@gmail.com
Post by Simon Kelley
DHCP that always binds the wildcard - doing otherwise _may_ be possible,
but be prepared for much testing and strange behaviour. For instance,
you need to be able to receive packets whose destination address in
255.255.255.255.
But the DHCP socket is (or can be with a config file setting) bound to
a particular interface, even if not a particular IP, correct?
At kernel level, it's not bound to anything. Dnsmasq sees DHCP packets
which arrive on all interfaces. The first thing it does is to filter
them based on --interface --except-interface and --no-dhcp-interface.
Anything which doesn't pass the filter is thrown away with no action.
The OP wants to be have the kernel do the filtering. There's no
practical benefit to doing that in most cases.
The benefit would be the ability to run multiple instances of dnsmasq
to serve different interfaces. I thought that capability existed.
It does, using a slightly different mechanism. You need to set "bind
interfaces" for the DNS stuff, and that also sets a flag on the DHCP
socket so that more than one interface is allowed to listen on 0.0.0.0

It's important to make sure that only one instance serves a particular
network; if this is not done, strange things may occur.


Simon.

Loading...