On 27/03/12 15:18, Mark Wu wrote:
Hi Simon,
It seems that dnsmasq always listen on wildcard network interfaces for
dhcp services even with the option "--interface" or "--listen-address"
specified. And you gave the following explanation for that:
Because a DHCP server has to cope with "strange" packets from
unconfigured and half-configured clients, it's not possible always to
bind the DHCP listening socket to an IP address.
It's copied from:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/307328/comments/1
Could you please elaborate more about the "strange" packets ? Actually,
the listening interface is configurable in the command line of dhcpd
daemon (http://www.isc.org/software/dhcp) I think it could help avoid
security risk and/or data privacy breach. Especially, when dnsmasq is
used by libvirt, it doesn't make sense that dnsmasq listens on anly
physical network interface. So do you think we could make the options
"--listen-address" and "--interface" applied to dhcp service too like
dns service in dnsmasq?
First, don't think that because dnsmasq binds the wildcard address, it
will provide service on any interface. If you run dnsmasq with
--interface=eth0, then any DHCP requests which arrive via other
interfaces will be discarded at the first stage of packet processing in
dnsmasq.
The strange packets have source address 0.0.0.0 and/or destination
address 255.255.255.255. When an socket is bound to a particular
address, it may not receive these packets. Some kernels work fine, but
it's really moving into undefined territory and portable code which
works everywhere is much easier when binding the wildcard.
Beware of comparisons with ISC dhcpd. It binds individual interface
addresses, as you suggest, but it only uses those for the non-"strange"
packets exchanged with fully configured hosts. dhcpd also opens the BPF
or LPF raw packet socket for the "strange" packets. So in fact, far from
limiting itself to the packets from a single interface, dhcpd (with the
help of BPF filters) is receiving and inspecting every single packet
which arrives at the host. That's probably a bigger attack surface than
dnsmasq has: it only needs to filter based on interface.
As to which approach is best, that's debatable. Dnsmasq's approach
doesn't make the host inspect and demultiplex every packet twice (one in
the IP stack and once in the packet filter) and it's more portable. (the
ISC method needs different raw-packet access code for each platform) On
the other hand, to be safe it needs binding the wildcard interface,
which can cause problems, especially trying to run multiple daemons
which listen on the same port.
This is something that was got right in DHCPv6. It's all done via
multicast using well-defined portable APIs.
HTH
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
