Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify
that?
-A: Yes, they do, so technically dnsmasq is not RFC-compliant. In practice, the
- sorts of queries which dnsmasq is used for are always sent via UDP. Adding
- TCP support would make dnsmasq much more heavyweight for no practical
- benefit. If you really want to do zone transfers, forward port 53 TCP
- using in-kernel port-forwarding or a port-fowarder like rinetd.
-
+A: Update: from version 2.10, it does. There are a few limitations:
+ data obtained via TCP is not cached, and dynamically-created
+ interfaces may break under certain circumstances. Source-address
+ or query-port specifications are ignored for TCP.
Q: When I send SIGUSR1 to dump the contents of the cache, some entries have
no IP address and are for names like mymachine.mydomain.com.mydomain.com.
For instance to send reverse queries on the range 192.168.0.0 to
192.168.0.255 to a nameserver at 10.0.0.1 do
server=/0.168.192.in-addr.arpa/10.0.0.1
+ Note that the "bogus-priv" option take priority over this option,
+ so the above will not work when the bogus-priv option is set.
Q: Dnsmasq fails to start with an error like this: "dnsmasq: bind
failed: Cannot assign requested address". What's the problem?
send with the "hostname" keyword in /etc/network/interfaces. (See
"man interfaces" for details.) That doesn't work for dhclient, were
you have to add something like "send host-name daisy" to
- /etc/dhclient.conf
+ /etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send
+ the hostname by default.
Q: I'm network booting my machines, and trying to give them static
DHCP-assigned addresses. The machine gets its correct address
the MAC address has a static allocation, that address is still in
use by the first incarnation of the machine (the one from the boot,
without a client ID.) dnsmasq therefore has to give the machine a
- dynamic address from its pool. There are two ways to solve this:
+ dynamic address from its pool. There are three ways to solve this:
(1) persuade your DHCP client not to send a client ID, or (2) set up
the static assignment to the client ID, not the MAC address. The
default client-id will be 01:<MAC address>, so change the dhcp-host
line from "dhcp-host=11:22:33:44:55:66,1.2.3.4" to
- "dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4"
+ "dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4" or (3) tell dnsmasq to
+ ignore client IDs for a particular MAC address, like this:
+ dhcp-host=11:22:33:44:55:66,id:*
Q: What network types are supported by the DHCP server?
A: Ethernet (and 802.11 wireless) are supported on all platforms. On
Linux Token Ring is also supported.
-
-
-
-
+Q: What is this strange "bind-interface" option?
+
+A: The DNS spec says that the reply to a DNS query must come from the
+ same address it was sent to. The traditional way to write an UDP
+ server to do this is to find all of the addresses belonging to the
+ machine (ie all the interfaces on the machine) and then create a
+ socket for each interface which is bound to the address of the
+ interface. Then when a packet is sent to address A, it is received
+ on the socket bound to address A and when the reply is also sent
+ via that socket, the source address is set to A by the kernel and
+ everything works. This is the how dnsmasq works when
+ "bind-interfaces" is set, with the obvious extension that is misses
+ out creating sockets for some interfaces depending on the
+ --interface, --address and --except-interface flags. The
+ disadvantage of this approach is that it breaks if interfaces don't
+ exist or are not configured when the daemon starts and does the
+ socket creation step. In a hotplug-aware world this is a real
+ problem.
+
+ The alternative approach is to have only one socket, which is bound
+ to the correct port and the wildcard IP address (0.0.0.0). That
+ socket will receive _all_ packets sent to port 53, no matter what
+ destination address they have. This solves the problem of
+ interfaces which are created or reconfigured after daemon
+ start-up. To make this work is more complicated because of the
+ "reply source address" problem. When a UDP packet is sent by a
+ socket bound to 0.0.0.0 its source address will be set to the
+ address of one of the machine's interfaces, but which one is not
+ determined and can vary depending on the OS being run. To get round
+ 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
+ address in the reply. For IPv4 this stuff in non-portable and quite
+ often not even available (It's different between FreeBSD 5.x and
+ Linux, for instance, and FreeBSD 4.x, Linux 2.0.x and OpenBSD don't
+ have it at all.) Hence "bind-interfaces" has to always be available
+ as a fall back. For IPv6 the API is standard and universally
+ available.
+
+ It could be argued that if the --interface or --address flags are
+ used then binding interfaces is more appropriate, but using
+ wildcard binding means that dnsmasq will quite happily start up
+ after being told to use interfaces which don't exist, but which are
+ created later. Wildcard binding breaks the scenario when dnsmasq is
+ listening on one interface and another server (most probably BIND)
+ is listening on another. It's not possible for BIND to bind to an
+ (address,port) pair when dnsmasq has bound (wildcard,port), hence
+ the ability to explicitly turn off wildcard binding.
+
+Q: Why doesn't Kerberos work/why can't I get sensible answers to
+ queries for SRV records.
+
+A: Probably because you have the "filterwin2k" option set. Note that
+ it was on by default in example configuration files included in
+ versions before 2.12, so you might have it set on without
+ realising.
+
+Q: Can I get email notification when a new version of dnsmasq is
+ released?
+
+A: Yes, new releases of dnsmasq are always announced through
+ freshmeat.net, and they allow you to subcribe to email alerts when
+ new versions of particular projects are released.
+
+Q: What does the dhcp-authoritative option do?
+
+A: See http://www.isc.org/index.pl?/sw/dhcp/authoritative.php - that's
+ for the ISC daemon, but the same applies to dnsmasq.
+
+Q: Why does my Gentoo box pause for a minute before getting a new
+ lease?
+
+A: Because when a Gentoo box shuts down, it releases its lease with
+ the server but remembers it on the client; this seems to be a
+ Gentoo-specific patch to dhcpcd. On restart it tries to renew
+ a lease which is long gone, as far as dnsmasq is concerned, and
+ dnsmasq ignores it until is times out and restarts the process.
+ To fix this, set the dhcp-authoritative flag in dnsmasq.
+
+
+
+
+
projects / people / ms / dnsmasq.git / blobdiff