Q: Why does dnsmasq open UDP ports >1024 as well as port 53.
Is this a security problem/trojan/backdoor?
-A: The high ports that dnsmasq opens is for replies from the upstream
+A: The high ports that dnsmasq opens are for replies from the upstream
nameserver(s). Queries from dnsmasq to upstream nameservers are sent
from these ports and replies received to them. The reason for doing this is
that most firewall setups block incoming packets _to_ port 53, in order
you to specify the UDP port to be used for this purpose. If not
specified, the operating system will select an available port number
just as it did before.
+
+ Second addendum: following the discovery of a security flaw in the
+ DNS protocol, dnsmasq from version 2.43 has changed behavior. It
+ now uses a new, randomly selected, port for each query. The old
+ default behaviour (use one port allocated by the OS) is available by
+ setting --query-port=0, and setting the query port to a positive
+ value still works. You should think hard and know what you are
+ doing before using either of these options.
Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify
that?
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
+ data obtained via TCP is not cached, and 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
Q: Will dnsmasq compile/run on non-Linux systems?
-A: Yes, there is explicit support for *BSD and Solaris.
+A: Yes, there is explicit support for *BSD and MacOS X and Solaris.
+ There are start-up scripts for MacOS X Tiger and Panther
+ in /contrib. Dnsmasq will link with uclibc to provide small
+ binaries suitable for use in embedded systems such as
+ routers. (There's special code to support machines with flash
+ filesystems and no battery-backed RTC.)
+ If you encounter make errors with *BSD, try installing gmake from
+ ports and building dnsmasq with "make MAKE=gmake"
For other systems, try altering the settings in config.h.
-
-A: Update for V2. Doing DHCP is rather non-portable, so there may be
- a few teething troubles. The initial 2.0 release is known to work
- on Linux 2.2.x, Linux 2.4.x and Linux 2.6.x with uclibc and glibc
- 2.3. It also works on FreeBSD 4.8. The crucial problem is sending
- raw packets, bypassing the IP stack. Dnsmasq contains code to do
- using PF_PACKET sockets (which is for Linux) and the Berkeley packet
- filter (which works with BSD). If you are trying to port to another
- Un*x, bpf is the most likeley candidate. See config.h
-
-Q: My companies' nameserver knows about some names which aren't in the
+
+Q: My company's nameserver knows about some names which aren't in the
public DNS. Even though I put it first in /etc/resolv.conf, it
dosen't work: dnsmasq seems not to use the nameservers in the order
given. What am I doing wrong?
Q: I'm running on BSD and dnsmasq won't accept long options on the
command line.
-A: Dnsmasq when built on BSD systems doesn't use GNU getopt by
+A: Dnsmasq when built on some BSD systems doesn't use GNU getopt by
default. You can either just use the single-letter options or
change config.h and the Makefile to use getopt-long. Note that
options in /etc/dnsmasq.conf must always be the long form,
"ping" will get a lookup failure, appending a dot to the end of the
hostname will fix things. (ie "ping myhost" fails, but "ping
myhost." works. The solution is to make sure that all your hosts
- have a domain set ("domain" in resolv.conf, the network applet in
- windows, or set a domain in your DHCP server). Any domain will do,
- but "localnet" is traditional. Now when you resolve "myhost" the
- resolver will attempt to look up "myhost.localnet" so you need to
- have dnsmasq reply to that name. The way to do that is to include
- the domain in each name on /etc/hosts and/or to use the
- --expand-hosts and --domain-suffix options.
+ have a domain set ("domain" in resolv.conf, or set a domain in
+ your DHCP server, see below for Windows XP and Mac OS X).
+ Any domain will do, but "localnet" is traditional. Now when you
+ resolve "myhost" the resolver will attempt to look up
+ "myhost.localnet" so you need to have dnsmasq reply to that name.
+ The way to do that is to include the domain in each name on
+ /etc/hosts and/or to use the --expand-hosts and --domain options.
+
+Q: How do I set the DNS domain in Windows XP or MacOS X (ref: previous
+ question)?
+
+A: for XP, Control Panel > Network Connections > { Connection to gateway /
+ DNS } > Properties > { Highlight TCP/IP } > Properties > Advanced >
+ DNS Tab > DNS suffix for this connection:
+
+A: for OS X, System Preferences > Network > {Connection to gateway / DNS } >
+ Search domains:
Q: Can I get dnsmasq to save the contents of its cache to disk when
- I shut my machine down and re-load when it starts again.
+ I shut my machine down and re-load when it starts again?
A: No, that facility is not provided. Very few names in the DNS have
their time-to-live set for longer than a few hours so most of the
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
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.
+ Linux all network types (including FireWire) are supported.
+
+Q: What are these strange "bind-interface" and "bind-dynamic" options?
+
+A: Dnsmasq from v2.63 can operate in one of three different "networking
+ modes". This is unfortunate as it requires users configuring dnsmasq
+ to take into account some rather bizzare contraints and select the
+ mode which best fits the requirements of a particular installation.
+ The origin of these are deficiencies in the Unix networking
+ model and APIs and each mode has different advantages and
+ problems. Just to add to the confusion, not all modes are available on
+ all platforms (due the to lack of supporting network APIs).To further
+ add to the confusion, the rules for the DHCP subsystem on dnsmasq are
+ different to the rules for the DNS and TFTP subsystems.
+
+ The three modes are "wildcard", "bind-interfaces" and "bind-dynamic".
+
+ In "wildcard" mode, dnsmasq binds the wildcard IP address (0.0.0.0 or
+ ::). This allows it to recieve all the packets sent to the server on
+ the relevant port. Access control (--interface, --except-interface,
+ --listen-address, etc) is implemented by dnsmasq: it queries the
+ kernel to determine the interface on which a packet was recieved and
+ the address to which it was sent, and applies the configured
+ rules. Wildcard mode is the default if neither of the other modes are
+ specified.
+
+ In "bind-interfaces" mode, dnsmasq runs through all the network
+ interfaces available when it starts, finds the set of IP addresses on
+ those interfaces, filters that set using the access control
+ configuration, and then binds the set of IP addresses. Only packets
+ sent to the allowed addresses are delivered by the kernel to dnsmasq.
+
+ In "bind-dynamic" mode, access control filtering is done both by
+ binding individual IP addresses, as for bind-interfaces, and by
+ inspecting individual packets on arrival as for wildcard mode. In
+ addition, dnsmasq notices when new interfaces appear or new addresses
+ appear on existing interfaces, and the resulting IP addresses are
+ bound automatically without having to restart dnsmasq.
+
+ The mode chosen has four different effects: co-existence with other
+ servers, semantics of --interface access control, effect of new
+ interfaces, and legality of --interface specifications for
+ non-existent inferfaces. We will deal with these in order.
+
+ A dnsmasq instance running in wildcard mode precludes a machine from
+ running a second instance of dnsmasq or any other DNS, TFTP or DHCP
+ server. Attempts to do so will fail with an "address in use" error.
+ Dnsmasq running in --bind-interfaces or bind-dynamic mode allow other
+ 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
queries for SRV records.
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. New releases are
+ also announced in the dnsmasq-discuss mailing list, subscribe at
+ http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
+
+Q: What does the dhcp-authoritative option do?
+
+A: See http://www.isc.org/files/auth.html - 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.
+
+Q: My laptop has two network interfaces, a wired one and a wireless
+ one. I never use both interfaces at the same time, and I'd like the
+ same IP and configuration to be used irrespective of which
+ interface is in use. How can I do that?
+
+A: By default, the identity of a machine is determined by using the
+ MAC address, which is associated with interface hardware. Once an
+ IP is bound to the MAC address of one interface, it cannot be
+ associated with another MAC address until after the DHCP lease
+ expires. The solution to this is to use a client-id as the machine
+ identity rather than the MAC address. If you arrange for the same
+ client-id to sent when either interface is in use, the DHCP server
+ will recognise the same machine, and use the same address. The
+ method for setting the client-id varies with DHCP client software,
+ dhcpcd uses the "-I" flag. Windows uses a registry setting,
+ see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm
+Addendum:
+ From version 2.46, dnsmasq has a solution to this which doesn't
+ involve setting client-IDs. It's possible to put more than one MAC
+ address in a --dhcp-host configuration. This tells dnsmasq that it
+ should use the specified IP for any of the specified MAC addresses,
+ and furthermore it gives dnsmasq permission to sumarily abandon a
+ lease to one of the MAC addresses if another one comes along. Note
+ that this will work fine only as longer as only one interface is
+ up at any time. There is no way for dnsmasq to enforce this
+ constraint: if you configure multiple MAC addresses and violate
+ this rule, bad things will happen.
+
+Q: Can dnsmasq do DHCP on IP-alias interfaces?
+
+A: Yes, from version-2.21. The support is only available running under
+ Linux, on a kernel which provides the RT-netlink facility. All 2.4
+ and 2.6 kernels provide RT-netlink and it's an option in 2.2
+ kernels.
+
+ If a physical interface has more than one IP address or aliases
+ with extra IP addresses, then any dhcp-ranges corresponding to
+ these addresses can be used for address allocation. So if an
+ interface has addresses 192.168.1.0/24 and 192.168.2.0/24 and there
+ are DHCP ranges 192.168.1.100-192.168.1.200 and
+ 192.168.2.100-192.168.2.200 then both ranges would be used for host
+ connected to the physical interface. A more typical use might be to
+ have one of the address-ranges as static-only, and have known
+ hosts allocated addresses on that subnet using dhcp-host options,
+ while anonymous hosts go on the other.
+
+
+Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
+ to do a recursive query" and DNS stops working. What's going on?
+
+A: Probably the nameserver is an authoritative nameserver for a
+ particular domain, but is not configured to answer general DNS
+ queries for an arbitrary domain. It is not suitable for use by
+ dnsmasq as an upstream server and should be removed from the
+ configuration. Note that if you have more than one upstream
+ nameserver configured dnsmasq will load-balance across them and
+ it may be some time before dnsmasq gets around to using a
+ particular nameserver. This means that a particular configuration
+ may work for sometime with a broken upstream nameserver
+ configuration.
+
+
+Q: Does the dnsmasq DHCP server probe addresses before allocating
+ them, as recommended in RFC2131?
+
+A: Yes, dynamically allocated IP addresses are checked by sending an
+ ICMP echo request (ping). If a reply is received, then dnsmasq
+ assumes that the address is in use, and attempts to allocate an
+ different address. The wait for a reply is between two and three
+ seconds. Because the DHCP server is not re-entrant, it cannot serve
+ other DHCP requests during this time. To avoid dropping requests,
+ the address probe may be skipped when dnsmasq is under heavy load.
+
+
+Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
+ DHCP doesn't work. What's the problem?
+
+A: This a variant on the iptables problem. Explicit details on how to
+ proceed can be found at
+ http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html
+
+
+Q: I'm using dnsmasq on a machine with the shorewall firewall, and
+ DHCP doesn't work. What's the problem?
+
+A: This a variant on the iptables problem. Explicit details on how to
+ proceed can be found at
+ http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html
+
+
+Q: Dnsmasq fails to start up with a message about capabilities.
+ Why did that happen and what can do to fix it?
+
+A: Change your kernel configuration: either deselect CONFIG_SECURITY
+ _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can
+ remove the need to set capabilities by running dnsmasq as root.
+
+
+Q: Where can I get .rpms Suitable for openSUSE/SLES?
+
+A: Dnsmasq is in openSUSE itself, and the latest releases are also
+ available at http://download.opensuse.org/repositories/network/
+
+
+Q: Can I run dnsmasq in a Linux vserver?
+
+A: Yes, as a DNS server, dnsmasq will just work in a vserver.
+ To use dnsmasq's DHCP function you need to give the vserver
+ extra system capabilities. Please note that doing so will lesser
+ the overall security of your system. The capabilities
+ required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW
+ is required to do an ICMP "ping" check on newly allocated
+ addresses. If you don't need this check, you can disable it with
+ --no-ping and omit the NET_RAW capability.
+ Adding the capabilities is done by adding them, one per line, to
+ either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or
+ /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please
+ refer to the vserver documentation for more information).
+
+
+Q: What's the problem with syslog and dnsmasq?
+
+A: In almost all cases: none. If you have the normal arrangement with
+ local daemons logging to a local syslog, which then writes to disk,
+ then there's never a problem. If you use network logging, then
+ there's a potential problem with deadlock: the syslog daemon will
+ do DNS lookups so that it can log the source of log messages,
+ these lookups will (depending on exact configuration) go through
+ dnsmasq, which also sends log messages. With bad timing, you can
+ arrive at a situation where syslog is waiting for dnsmasq, and
+ dnsmasq is waiting for syslog; they will both wait forever. This
+ problem is fixed from dnsmasq-2.39, which introduces asynchronous
+ logging: dnsmasq no longer waits for syslog and the deadlock is
+ broken. There is a remaining problem in 2.39, where "log-queries"
+ is in use. In this case most DNS queries generate two log lines, if
+ these go to a syslog which is doing a DNS lookup for each log line,
+ then those queries will in turn generate two more log lines, and a
+ chain reaction runaway will occur. To avoid this, use syslog-ng
+ and turn on syslog-ng's dns-cache function.
+
+
+Q: DHCP doesn't work with windows Vista, but everything else is fine.
+
+A: The DHCP client on windows Vista (and possibly later versions)
+ demands that the DHCP server send replies as broadcasts. Most other
+ clients don't do this. The broadcasts are send to
+ 255.255.255.255. A badly configured firewall which blocks such
+ packets will show exactly these symptoms (Vista fails, others
+ work).
+
+
+Q: DHCP doesn't work with windows 7 but everything else is fine.
+
+A: There seems to be a problem if Windows 7 doesn't get a value for
+ DHCP option 252 in DHCP packets it gets from the server. The
+ symtoms have beeen variously reported as continual DHCPINFORM
+ requests in an attempt to get an option-252, or even ignoring DHCP
+ offers completely (and failing to get an IP address) if there is no
+ option-252 supplied. DHCP option 252 is for WPAD, WWW Proxy
+ Auto Detection and if you don't want or need to use that, then
+ simplest fix seems to be to supply an empty option with:
+
+ dhcp-option=252,"\n"
+
+
+
+
+
+
+
+
+
projects / people / ms / dnsmasq.git / blobdiff