Annotation of embedaddon/dnsmasq/FAQ, revision 1.1.1.1
1.1 misho 1: Q: Why does dnsmasq open UDP ports >1024 as well as port 53.
2: Is this a security problem/trojan/backdoor?
3:
4: A: The high ports that dnsmasq opens are for replies from the upstream
5: nameserver(s). Queries from dnsmasq to upstream nameservers are sent
6: from these ports and replies received to them. The reason for doing this is
7: that most firewall setups block incoming packets _to_ port 53, in order
8: to stop DNS queries from the outside world. If dnsmasq sent its queries
9: from port 53 the replies would be _to_ port 53 and get blocked.
10:
11: This is not a security hole since dnsmasq will only accept replies to that
12: port: queries are dropped. The replies must be to oustanding queries
13: which dnsmasq has forwarded, otherwise they are dropped too.
14:
15: Addendum: dnsmasq now has the option "query-port" (-Q), which allows
16: you to specify the UDP port to be used for this purpose. If not
17: specified, the operating system will select an available port number
18: just as it did before.
19:
20: Second addendum: following the discovery of a security flaw in the
21: DNS protocol, dnsmasq from version 2.43 has changed behavior. It
22: now uses a new, randomly selected, port for each query. The old
23: default behaviour (use one port allocated by the OS) is available by
24: setting --query-port=0, and setting the query port to a positive
25: value still works. You should think hard and know what you are
26: doing before using either of these options.
27:
28: Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify
29: that?
30:
31: A: Update: from version 2.10, it does. There are a few limitations:
32: data obtained via TCP is not cached, and source-address
33: or query-port specifications are ignored for TCP.
34:
35: Q: When I send SIGUSR1 to dump the contents of the cache, some entries have
36: no IP address and are for names like mymachine.mydomain.com.mydomain.com.
37: What are these?
38:
39: A: They are negative entries: that's what the N flag means. Dnsmasq asked
40: an upstream nameserver to resolve that address and it replied "doesn't
41: exist, and won't exist for <n> hours" so dnsmasq saved that information so
42: that if _it_ gets asked the same question it can answer directly without
43: having to go back to the upstream server again. The strange repeated domains
44: result from the way resolvers search short names. See "man resolv.conf" for
45: details.
46:
47:
48: Q: Will dnsmasq compile/run on non-Linux systems?
49:
50: A: Yes, there is explicit support for *BSD and MacOS X and Solaris.
51: There are start-up scripts for MacOS X Tiger and Panther
52: in /contrib. Dnsmasq will link with uclibc to provide small
53: binaries suitable for use in embedded systems such as
54: routers. (There's special code to support machines with flash
55: filesystems and no battery-backed RTC.)
56: If you encounter make errors with *BSD, try installing gmake from
57: ports and building dnsmasq with "make MAKE=gmake"
58: For other systems, try altering the settings in config.h.
59:
60: Q: My company's nameserver knows about some names which aren't in the
61: public DNS. Even though I put it first in /etc/resolv.conf, it
62: dosen't work: dnsmasq seems not to use the nameservers in the order
63: given. What am I doing wrong?
64:
65: A: By default, dnsmasq treats all the nameservers it knows about as
66: equal: it picks the one to use using an algorithm designed to avoid
67: nameservers which aren't responding. To make dnsmasq use the
68: servers in order, give it the -o flag. If you want some queries
69: sent to a special server, think about using the -S flag to give the
70: IP address of that server, and telling dnsmasq exactly which
71: domains to use the server for.
72:
73: Q: OK, I've got queries to a private nameserver working, now how about
74: reverse queries for a range of IP addresses?
75:
76: A: Use the standard DNS convention of <reversed address>.in-addr.arpa.
77: For instance to send reverse queries on the range 192.168.0.0 to
78: 192.168.0.255 to a nameserver at 10.0.0.1 do
79: server=/0.168.192.in-addr.arpa/10.0.0.1
80: Note that the "bogus-priv" option take priority over this option,
81: so the above will not work when the bogus-priv option is set.
82:
83: Q: Dnsmasq fails to start with an error like this: "dnsmasq: bind
84: failed: Cannot assign requested address". What's the problem?
85:
86: A: This has been seen when a system is bringing up a PPP interface at
87: boot time: by the time dnsmasq start the interface has been
88: created, but not brought up and assigned an address. The easiest
89: solution is to use --interface flags to specify which interfaces
90: dnsmasq should listen on. Since you are unlikely to want dnsmasq to
91: listen on a PPP interface and offer DNS service to the world, the
92: problem is solved.
93:
94: Q: I'm running on BSD and dnsmasq won't accept long options on the
95: command line.
96:
97: A: Dnsmasq when built on some BSD systems doesn't use GNU getopt by
98: default. You can either just use the single-letter options or
99: change config.h and the Makefile to use getopt-long. Note that
100: options in /etc/dnsmasq.conf must always be the long form,
101: on all platforms.
102:
103: Q: Names on the internet are working fine, but looking up local names
104: from /etc/hosts or DHCP doesn't seem to work.
105:
106: A: Resolver code sometime does strange things when given names without
107: any dots in. Win2k and WinXP may not use the DNS at all and just
108: try and look up the name using WINS. On unix look at "options ndots:"
109: in "man resolv.conf" for details on this topic. Testing lookups
110: using "nslookup" or "dig" will work, but then attempting to run
111: "ping" will get a lookup failure, appending a dot to the end of the
112: hostname will fix things. (ie "ping myhost" fails, but "ping
113: myhost." works. The solution is to make sure that all your hosts
114: have a domain set ("domain" in resolv.conf, or set a domain in
115: your DHCP server, see below for Windows XP and Mac OS X).
116: Any domain will do, but "localnet" is traditional. Now when you
117: resolve "myhost" the resolver will attempt to look up
118: "myhost.localnet" so you need to have dnsmasq reply to that name.
119: The way to do that is to include the domain in each name on
120: /etc/hosts and/or to use the --expand-hosts and --domain options.
121:
122: Q: How do I set the DNS domain in Windows XP or MacOS X (ref: previous
123: question)?
124:
125: A: for XP, Control Panel > Network Connections > { Connection to gateway /
126: DNS } > Properties > { Highlight TCP/IP } > Properties > Advanced >
127: DNS Tab > DNS suffix for this connection:
128:
129: A: for OS X, System Preferences > Network > {Connection to gateway / DNS } >
130: Search domains:
131:
132: Q: Can I get dnsmasq to save the contents of its cache to disk when
133: I shut my machine down and re-load when it starts again?
134:
135: A: No, that facility is not provided. Very few names in the DNS have
136: their time-to-live set for longer than a few hours so most of the
137: cache entries would have expired after a shutdown. For longer-lived
138: names it's much cheaper to just reload them from the upstream
139: server. Note that dnsmasq is not shut down between PPP sessions so
140: go off-line and then on-line again will not lose the contents of
141: the cache.
142:
143: Q: Who are Verisign, what do they have to do with the bogus-nxdomain
144: option in dnsmasq and why should I wory about it?
145:
146: A: [note: this was written in September 2003, things may well change.]
147: Versign run the .com and .net top-level-domains. They have just
148: changed the configuration of their servers so that unknown .com and
149: .net domains, instead of returning an error code NXDOMAIN, (no such
150: domain) return the address of a host at Versign which runs a web
151: server showing a search page. Most right-thinking people regard
152: this new behaviour as broken :-). You can test to see if you are
153: suffering Versign brokeness by run a command like
154:
155: host jlsdajkdalld.com
156:
157: If you get "jlsdajkdalld.com" does not exist, then all is fine, if
158: host returns an IP address, then the DNS is broken. (Try a few
159: different unlikely domains, just in case you picked a wierd one
160: which really _is_ registered.)
161:
162: Assuming that your DNS is broken, and you want to fix it, simply
163: note the IP address being returned and pass it to dnsmasq using the
164: --bogus-nxdomain flag. Dnsmasq will check for results returning
165: that address and substitute an NXDOMAIN instead.
166:
167: As of writing, the IP address in question for the .com and .net
168: domains is is 64.94.110.11. Various other, less prominent,
169: registries pull the same stunt; there is a list of them all, and
170: the addresses to block, at http://winware.org/bogus-domains.txt
171:
172: Q: This new DHCP server is well and good, but it doesn't work for me.
173: What's the problem?
174:
175: A: There are a couple of configuration gotchas which have been
176: encountered by people moving from the ISC dhcpd to the dnsmasq
177: integrated DHCP daemon. Both are related to differences in
178: in the way the two daemons bypass the IP stack to do "ground up"
179: IP configuration and can lead to the dnsmasq daemon failing
180: whilst the ISC one works.
181:
182: The first thing to check is the broadcast address set for the
183: ethernet interface. This is normally the adddress on the connected
184: network with all ones in the host part. For instance if the
185: address of the ethernet interface is 192.168.55.7 and the netmask
186: is 255.255.255.0 then the broadcast address should be
187: 192.168.55.255. Having a broadcast address which is not on the
188: network to which the interface is connected kills things stone
189: dead.
190:
191: The second potential problem relates to firewall rules: since the ISC
192: daemon in some configurations bypasses the kernel firewall rules
193: entirely, the ability to run the ISC daemon does not indicate
194: that the current configuration is OK for the dnsmasq daemon.
195: For the dnsmasq daemon to operate it's vital that UDP packets to
196: and from ports 67 and 68 and broadcast packets with source
197: address 0.0.0.0 and destination address 255.255.255.255 are not
198: dropped by iptables/ipchains.
199:
200: Q: I'm running Debian, and my machines get an address fine with DHCP,
201: but their names are not appearing in the DNS.
202:
203: A: By default, none of the DHCP clients send the host-name when asking
204: for a lease. For most of the clients, you can set the host-name to
205: send with the "hostname" keyword in /etc/network/interfaces. (See
206: "man interfaces" for details.) That doesn't work for dhclient, were
207: you have to add something like "send host-name daisy" to
208: /etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send
209: the hostname by default.
210:
211: Q: I'm network booting my machines, and trying to give them static
212: DHCP-assigned addresses. The machine gets its correct address
213: whilst booting, but then the OS starts and it seems to get
214: allocated a different address.
215:
216: A: What is happening is this: The boot process sends a DHCP
217: request and gets allocated the static address corresponding to its
218: MAC address. The boot loader does not send a client-id. Then the OS
219: starts and repeats the DHCP process, but it it does send a
220: client-id. Dnsmasq cannot assume that the two requests are from the
221: same machine (since the client ID's don't match) and even though
222: the MAC address has a static allocation, that address is still in
223: use by the first incarnation of the machine (the one from the boot,
224: without a client ID.) dnsmasq therefore has to give the machine a
225: dynamic address from its pool. There are three ways to solve this:
226: (1) persuade your DHCP client not to send a client ID, or (2) set up
227: the static assignment to the client ID, not the MAC address. The
228: default client-id will be 01:<MAC address>, so change the dhcp-host
229: line from "dhcp-host=11:22:33:44:55:66,1.2.3.4" to
230: "dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4" or (3) tell dnsmasq to
231: ignore client IDs for a particular MAC address, like this:
232: dhcp-host=11:22:33:44:55:66,id:*
233:
234: Q: What network types are supported by the DHCP server?
235:
236: A: Ethernet (and 802.11 wireless) are supported on all platforms. On
237: Linux all network types (including FireWire) are supported.
238:
239: Q: What are these strange "bind-interface" and "bind-dynamic" options?
240:
241: A: Dnsmasq from v2.63 can operate in one of three different "networking
242: modes". This is unfortunate as it requires users configuring dnsmasq
243: to take into account some rather bizzare contraints and select the
244: mode which best fits the requirements of a particular installation.
245: The origin of these are deficiencies in the Unix networking
246: model and APIs and each mode has different advantages and
247: problems. Just to add to the confusion, not all modes are available on
248: all platforms (due the to lack of supporting network APIs).To further
249: add to the confusion, the rules for the DHCP subsystem on dnsmasq are
250: different to the rules for the DNS and TFTP subsystems.
251:
252: The three modes are "wildcard", "bind-interfaces" and "bind-dynamic".
253:
254: In "wildcard" mode, dnsmasq binds the wildcard IP address (0.0.0.0 or
255: ::). This allows it to recieve all the packets sent to the server on
256: the relevant port. Access control (--interface, --except-interface,
257: --listen-address, etc) is implemented by dnsmasq: it queries the
258: kernel to determine the interface on which a packet was recieved and
259: the address to which it was sent, and applies the configured
260: rules. Wildcard mode is the default if neither of the other modes are
261: specified.
262:
263: In "bind-interfaces" mode, dnsmasq runs through all the network
264: interfaces available when it starts, finds the set of IP addresses on
265: those interfaces, filters that set using the access control
266: configuration, and then binds the set of IP addresses. Only packets
267: sent to the allowed addresses are delivered by the kernel to dnsmasq.
268:
269: In "bind-dynamic" mode, access control filtering is done both by
270: binding individual IP addresses, as for bind-interfaces, and by
271: inspecting individual packets on arrival as for wildcard mode. In
272: addition, dnsmasq notices when new interfaces appear or new addresses
273: appear on existing interfaces, and the resulting IP addresses are
274: bound automatically without having to restart dnsmasq.
275:
276: The mode chosen has four different effects: co-existence with other
277: servers, semantics of --interface access control, effect of new
278: interfaces, and legality of --interface specifications for
279: non-existent inferfaces. We will deal with these in order.
280:
281: A dnsmasq instance running in wildcard mode precludes a machine from
282: running a second instance of dnsmasq or any other DNS, TFTP or DHCP
283: server. Attempts to do so will fail with an "address in use" error.
284: Dnsmasq running in --bind-interfaces or bind-dynamic mode allow other
285: instances of dnsmasq or other servers, as long as no two servers are
286: configured to listen on the same interface address.
287:
288: The semantics of --interface varies subtly between wildcard or
289: bind-dynamic mode and bind-interfaces mode. The situation where this
290: matters is a request which arrives via one interface (A), but with a
291: destination address of a second interface (B) and when dnsmasq is
292: configured to listen only on B. In wildcard or bind-dynamic mode, such
293: a request will be ignored, in bind-interfaces mode, it will be
294: accepted.
295:
296: The creation of new network interfaces after dnsmasq starts is ignored
297: by dnsmasq when in --bind-interfaces mode. In wildcard or bind-dynamic
298: mode, such interfaces are handled normally.
299:
300: A --interface specification for a non-existent interface is a fatal
301: error at start-up when in --bind-interfaces mode, by just generates a
302: warning in wildcard or bind-dynamic mode.
303:
304: Q: Why doesn't Kerberos work/why can't I get sensible answers to
305: queries for SRV records.
306:
307: A: Probably because you have the "filterwin2k" option set. Note that
308: it was on by default in example configuration files included in
309: versions before 2.12, so you might have it set on without
310: realising.
311:
312: Q: Can I get email notification when a new version of dnsmasq is
313: released?
314:
315: A: Yes, new releases of dnsmasq are always announced through
316: freshmeat.net, and they allow you to subcribe to email alerts when
317: new versions of particular projects are released. New releases are
318: also announced in the dnsmasq-discuss mailing list, subscribe at
319: http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
320:
321: Q: What does the dhcp-authoritative option do?
322:
323: A: See http://www.isc.org/files/auth.html - that's
324: for the ISC daemon, but the same applies to dnsmasq.
325:
326: Q: Why does my Gentoo box pause for a minute before getting a new
327: lease?
328:
329: A: Because when a Gentoo box shuts down, it releases its lease with
330: the server but remembers it on the client; this seems to be a
331: Gentoo-specific patch to dhcpcd. On restart it tries to renew
332: a lease which is long gone, as far as dnsmasq is concerned, and
333: dnsmasq ignores it until is times out and restarts the process.
334: To fix this, set the dhcp-authoritative flag in dnsmasq.
335:
336: Q: My laptop has two network interfaces, a wired one and a wireless
337: one. I never use both interfaces at the same time, and I'd like the
338: same IP and configuration to be used irrespective of which
339: interface is in use. How can I do that?
340:
341: A: By default, the identity of a machine is determined by using the
342: MAC address, which is associated with interface hardware. Once an
343: IP is bound to the MAC address of one interface, it cannot be
344: associated with another MAC address until after the DHCP lease
345: expires. The solution to this is to use a client-id as the machine
346: identity rather than the MAC address. If you arrange for the same
347: client-id to sent when either interface is in use, the DHCP server
348: will recognise the same machine, and use the same address. The
349: method for setting the client-id varies with DHCP client software,
350: dhcpcd uses the "-I" flag. Windows uses a registry setting,
351: see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm
352: Addendum:
353: From version 2.46, dnsmasq has a solution to this which doesn't
354: involve setting client-IDs. It's possible to put more than one MAC
355: address in a --dhcp-host configuration. This tells dnsmasq that it
356: should use the specified IP for any of the specified MAC addresses,
357: and furthermore it gives dnsmasq permission to sumarily abandon a
358: lease to one of the MAC addresses if another one comes along. Note
359: that this will work fine only as longer as only one interface is
360: up at any time. There is no way for dnsmasq to enforce this
361: constraint: if you configure multiple MAC addresses and violate
362: this rule, bad things will happen.
363:
364: Q: Can dnsmasq do DHCP on IP-alias interfaces?
365:
366: A: Yes, from version-2.21. The support is only available running under
367: Linux, on a kernel which provides the RT-netlink facility. All 2.4
368: and 2.6 kernels provide RT-netlink and it's an option in 2.2
369: kernels.
370:
371: If a physical interface has more than one IP address or aliases
372: with extra IP addresses, then any dhcp-ranges corresponding to
373: these addresses can be used for address allocation. So if an
374: interface has addresses 192.168.1.0/24 and 192.168.2.0/24 and there
375: are DHCP ranges 192.168.1.100-192.168.1.200 and
376: 192.168.2.100-192.168.2.200 then both ranges would be used for host
377: connected to the physical interface. A more typical use might be to
378: have one of the address-ranges as static-only, and have known
379: hosts allocated addresses on that subnet using dhcp-host options,
380: while anonymous hosts go on the other.
381:
382:
383: Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
384: to do a recursive query" and DNS stops working. What's going on?
385:
386: A: Probably the nameserver is an authoritative nameserver for a
387: particular domain, but is not configured to answer general DNS
388: queries for an arbitrary domain. It is not suitable for use by
389: dnsmasq as an upstream server and should be removed from the
390: configuration. Note that if you have more than one upstream
391: nameserver configured dnsmasq will load-balance across them and
392: it may be some time before dnsmasq gets around to using a
393: particular nameserver. This means that a particular configuration
394: may work for sometime with a broken upstream nameserver
395: configuration.
396:
397:
398: Q: Does the dnsmasq DHCP server probe addresses before allocating
399: them, as recommended in RFC2131?
400:
401: A: Yes, dynamically allocated IP addresses are checked by sending an
402: ICMP echo request (ping). If a reply is received, then dnsmasq
403: assumes that the address is in use, and attempts to allocate an
404: different address. The wait for a reply is between two and three
405: seconds. Because the DHCP server is not re-entrant, it cannot serve
406: other DHCP requests during this time. To avoid dropping requests,
407: the address probe may be skipped when dnsmasq is under heavy load.
408:
409:
410: Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
411: DHCP doesn't work. What's the problem?
412:
413: A: This a variant on the iptables problem. Explicit details on how to
414: proceed can be found at
415: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html
416:
417:
418: Q: I'm using dnsmasq on a machine with the shorewall firewall, and
419: DHCP doesn't work. What's the problem?
420:
421: A: This a variant on the iptables problem. Explicit details on how to
422: proceed can be found at
423: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html
424:
425:
426: Q: Dnsmasq fails to start up with a message about capabilities.
427: Why did that happen and what can do to fix it?
428:
429: A: Change your kernel configuration: either deselect CONFIG_SECURITY
430: _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can
431: remove the need to set capabilities by running dnsmasq as root.
432:
433:
434: Q: Where can I get .rpms Suitable for openSUSE/SLES?
435:
436: A: Dnsmasq is in openSUSE itself, and the latest releases are also
437: available at http://download.opensuse.org/repositories/network/
438:
439:
440: Q: Can I run dnsmasq in a Linux vserver?
441:
442: A: Yes, as a DNS server, dnsmasq will just work in a vserver.
443: To use dnsmasq's DHCP function you need to give the vserver
444: extra system capabilities. Please note that doing so will lesser
445: the overall security of your system. The capabilities
446: required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW
447: is required to do an ICMP "ping" check on newly allocated
448: addresses. If you don't need this check, you can disable it with
449: --no-ping and omit the NET_RAW capability.
450: Adding the capabilities is done by adding them, one per line, to
451: either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or
452: /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please
453: refer to the vserver documentation for more information).
454:
455:
456: Q: What's the problem with syslog and dnsmasq?
457:
458: A: In almost all cases: none. If you have the normal arrangement with
459: local daemons logging to a local syslog, which then writes to disk,
460: then there's never a problem. If you use network logging, then
461: there's a potential problem with deadlock: the syslog daemon will
462: do DNS lookups so that it can log the source of log messages,
463: these lookups will (depending on exact configuration) go through
464: dnsmasq, which also sends log messages. With bad timing, you can
465: arrive at a situation where syslog is waiting for dnsmasq, and
466: dnsmasq is waiting for syslog; they will both wait forever. This
467: problem is fixed from dnsmasq-2.39, which introduces asynchronous
468: logging: dnsmasq no longer waits for syslog and the deadlock is
469: broken. There is a remaining problem in 2.39, where "log-queries"
470: is in use. In this case most DNS queries generate two log lines, if
471: these go to a syslog which is doing a DNS lookup for each log line,
472: then those queries will in turn generate two more log lines, and a
473: chain reaction runaway will occur. To avoid this, use syslog-ng
474: and turn on syslog-ng's dns-cache function.
475:
476:
477: Q: DHCP doesn't work with windows Vista, but everything else is fine.
478:
479: A: The DHCP client on windows Vista (and possibly later versions)
480: demands that the DHCP server send replies as broadcasts. Most other
481: clients don't do this. The broadcasts are send to
482: 255.255.255.255. A badly configured firewall which blocks such
483: packets will show exactly these symptoms (Vista fails, others
484: work).
485:
486:
487: Q: DHCP doesn't work with windows 7 but everything else is fine.
488:
489: A: There seems to be a problem if Windows 7 doesn't get a value for
490: DHCP option 252 in DHCP packets it gets from the server. The
491: symtoms have beeen variously reported as continual DHCPINFORM
492: requests in an attempt to get an option-252, or even ignoring DHCP
493: offers completely (and failing to get an IP address) if there is no
494: option-252 supplied. DHCP option 252 is for WPAD, WWW Proxy
495: Auto Detection and if you don't want or need to use that, then
496: simplest fix seems to be to supply an empty option with:
497:
498: dhcp-option=252,"\n"
499:
500:
501:
502:
503:
504:
505:
506:
507:
508:
509:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to FAQ CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dnsmasq