Commit 8223cb15 authored by Simon Kelley's avatar Simon Kelley

Update FAQ to cover --bind-dynamic.

parent 4ba9b38c
...@@ -236,53 +236,70 @@ Q: What network types are supported by the DHCP server? ...@@ -236,53 +236,70 @@ Q: What network types are supported by the DHCP server?
A: Ethernet (and 802.11 wireless) are supported on all platforms. On A: Ethernet (and 802.11 wireless) are supported on all platforms. On
Linux all network types (including FireWire) are supported. Linux all network types (including FireWire) are supported.
Q: What is this strange "bind-interface" option? Q: What are these strange "bind-interface" and "bind-dynamic" options?
A: The DNS spec says that the reply to a DNS query must come from the A: Dnsmasq from v2.63 can operate in one of three different "networking
same address it was sent to. The traditional way to write an UDP modes". This is unfortunate as it requires users configuring dnsmasq
server to do this is to find all of the addresses belonging to the to take into account some rather bizzare contraints and select the
machine (ie all the interfaces on the machine) and then create a mode which best fits the requirements of a particular installation.
socket for each interface which is bound to the address of the The origin of these are deficiencies in the Unix networking
interface. Then when a packet is sent to address A, it is received model and APIs and each mode has different advantages and
on the socket bound to address A and when the reply is also sent problems. Just to add to the confusion, not all modes are available on
via that socket, the source address is set to A by the kernel and all platforms (due the to lack of supporting network APIs).To further
everything works. This is the how dnsmasq works when add to the confusion, the rules for the DHCP subsystem on dnsmasq are
"bind-interfaces" is set, with the obvious extension that is misses different to the rules for the DNS and TFTP subsystems.
out creating sockets for some interfaces depending on the
--interface, --address and --except-interface flags. The The three modes are "wildcard", "bind-interfaces" and "bind-dynamic".
disadvantage of this approach is that it breaks if interfaces don't
exist or are not configured when the daemon starts and does the In "wildcard" mode, dnsmasq binds the wildcard IP address (0.0.0.0 or
socket creation step. In a hotplug-aware world this is a real ::). This allows it to recieve all the packets sent to the server on
problem. the relevant port. Access control (--interface, --except-interface,
--listen-address, etc) is implemented by dnsmasq: it queries the
The alternative approach is to have only one socket, which is bound kernel to determine the interface on which a packet was recieved and
to the correct port and the wildcard IP address (0.0.0.0). That the address to which it was sent, and applies the configured
socket will receive _all_ packets sent to port 53, no matter what rules. Wildcard mode is the default if neither of the other modes are
destination address they have. This solves the problem of specified.
interfaces which are created or reconfigured after daemon
start-up. To make this work is more complicated because of the In "bind-interfaces" mode, dnsmasq runs through all the network
"reply source address" problem. When a UDP packet is sent by a interfaces available when it starts, finds the set of IP addresses on
socket bound to 0.0.0.0 its source address will be set to the those interfaces, filters that set using the access control
address of one of the machine's interfaces, but which one is not configuration, and then binds the set of IP addresses. Only packets
determined and can vary depending on the OS being run. To get round sent to the allowed addresses are delivered by the kernel to dnsmasq.
this it is neccessary to use a scary advanced API to determine the
address to which a query was sent, and force that to be the source In "bind-dynamic" mode, access control filtering is done both by
address in the reply. For IPv4 this stuff in non-portable and quite binding individual IP addresses, as for bind-interfaces, and by
often not even available (It's different between FreeBSD 5.x and inspecting individual packets on arrival as for wildcard mode. In
Linux, for instance, and FreeBSD 4.x, Linux 2.0.x and OpenBSD don't addition, dnsmasq notices when new interfaces appear or new addresses
have it at all.) Hence "bind-interfaces" has to always be available appear on existing interfaces, and the resulting IP addresses are
as a fall back. For IPv6 the API is standard and universally bound automatically without having to restart dnsmasq.
available.
The mode chosen has four different effects: co-existence with other
It could be argued that if the --interface or --address flags are servers, semantics of --interface access control, effect of new
used then binding interfaces is more appropriate, but using interfaces, and legality of --interface specifications for
wildcard binding means that dnsmasq will quite happily start up non-existent inferfaces. We will deal with these in order.
after being told to use interfaces which don't exist, but which are
created later. Wildcard binding breaks the scenario when dnsmasq is A dnsmasq instance running in wildcard mode precludes a machine from
listening on one interface and another server (most probably BIND) running a second instance of dnsmasq or any other DNS, TFTP or DHCP
is listening on another. It's not possible for BIND to bind to an server. Attempts to do so will fail with an "address in use" error.
(address,port) pair when dnsmasq has bound (wildcard,port), hence Dnsmasq running in --bind-interfaces or bind-dynamic mode allow other
the ability to explicitly turn off wildcard binding. instances of dnsmasq or other servers, as long as no two servers are
configured to listen on the same interface address.
The semantics of --interface varies subtly between wildcard or
bind-dynamic mode and bind-interfaces mode. The situation where this
matters is a request which arrives via one interface (A), but with a
destination address of a second interface (B) and when dnsmasq is
configured to listen only on B. In wildcard or bind-dynamic mode, such
a request will be ignored, in bind-interfaces mode, it will be
accepted.
The creation of new network interfaces after dnsmasq starts is ignored
by dnsmasq when in --bind-interfaces mode. In wildcard or bind-dynamic
mode, such interfaces are handled normally.
A --interface specification for a non-existent interface is a fatal
error at start-up when in --bind-interfaces mode, by just generates a
warning in wildcard or bind-dynamic mode.
Q: Why doesn't Kerberos work/why can't I get sensible answers to Q: Why doesn't Kerberos work/why can't I get sensible answers to
queries for SRV records. queries for SRV records.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment