Annotation of embedaddon/dnsmasq/FAQ, revision 1.1.1.2
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
1.1.1.2 ! misho 12: port: queries are dropped. The replies must be to outstanding queries
1.1 misho 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
1.1.1.2 ! misho 62: doesn't work: dnsmasq seems not to use the nameservers in the order
1.1 misho 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.]
1.1.1.2 ! misho 147: Verisign run the .com and .net top-level-domains. They have just
1.1 misho 148: changed the configuration of their servers so that unknown .com and
149: .net domains, instead of returning an error code NXDOMAIN, (no such
1.1.1.2 ! misho 150: domain) return the address of a host at Verisign which runs a web
1.1 misho 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
1.1.1.2 ! misho 153: suffering Verisign brokenness by run a command like
1.1 misho 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
1.1.1.2 ! misho 159: different unlikely domains, just in case you picked a weird one
1.1 misho 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
1.1.1.2 ! misho 183: ethernet interface. This is normally the address on the connected
1.1 misho 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
1.1.1.2 ! misho 208: /etc/dhclient.conf [Update: the latest dhcpcd packages _do_ send
1.1 misho 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
1.1.1.2 ! misho 243: to take into account some rather bizarre constraints and select the
1.1 misho 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
1.1.1.2 ! misho 255: ::). This allows it to receive all the packets sent to the server on
1.1 misho 256: the relevant port. Access control (--interface, --except-interface,
257: --listen-address, etc) is implemented by dnsmasq: it queries the
1.1.1.2 ! misho 258: kernel to determine the interface on which a packet was received and
1.1 misho 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
1.1.1.2 ! misho 279: non-existent interfaces. We will deal with these in order.
1.1 misho 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:
1.1.1.2 ! misho 300: An --interface specification for a non-existent interface is a fatal
1.1 misho 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
1.1.1.2 ! misho 316: freshmeat.net, and they allow you to subscribe to email alerts when
1.1 misho 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:
1.1.1.2 ! misho 323: A: The DHCP spec says that when a DHCP server receives a renewal request
! 324: from a client it has no knowledge of, it should just ignore it.
! 325: This is because it's supported to have more than one DHCP server
! 326: on a network, and another DHCP server may be dealing with the client.
! 327: This has the unfortunate effect that when _no_ DHCP replies to
! 328: the client, it takes some time for the client to time-out and start
! 329: to get a new lease. Setting this option makes dnsmasq violate the
! 330: standard to the extent that it will send a NAK reply to the client,
! 331: causing it to immediately start to get a new lease. This improves
! 332: behaviour when machines move networks, and in the case that the DHCP
! 333: lease database is lost. As long as there are not more tha one DHCP
! 334: server on the network, it's safe to enable the option.
1.1 misho 335:
336: Q: Why does my Gentoo box pause for a minute before getting a new
337: lease?
338:
339: A: Because when a Gentoo box shuts down, it releases its lease with
340: the server but remembers it on the client; this seems to be a
341: Gentoo-specific patch to dhcpcd. On restart it tries to renew
342: a lease which is long gone, as far as dnsmasq is concerned, and
343: dnsmasq ignores it until is times out and restarts the process.
344: To fix this, set the dhcp-authoritative flag in dnsmasq.
345:
346: Q: My laptop has two network interfaces, a wired one and a wireless
347: one. I never use both interfaces at the same time, and I'd like the
348: same IP and configuration to be used irrespective of which
349: interface is in use. How can I do that?
350:
351: A: By default, the identity of a machine is determined by using the
352: MAC address, which is associated with interface hardware. Once an
353: IP is bound to the MAC address of one interface, it cannot be
354: associated with another MAC address until after the DHCP lease
355: expires. The solution to this is to use a client-id as the machine
356: identity rather than the MAC address. If you arrange for the same
357: client-id to sent when either interface is in use, the DHCP server
358: will recognise the same machine, and use the same address. The
359: method for setting the client-id varies with DHCP client software,
360: dhcpcd uses the "-I" flag. Windows uses a registry setting,
361: see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm
1.1.1.2 ! misho 362:
1.1 misho 363: Addendum:
364: From version 2.46, dnsmasq has a solution to this which doesn't
365: involve setting client-IDs. It's possible to put more than one MAC
366: address in a --dhcp-host configuration. This tells dnsmasq that it
367: should use the specified IP for any of the specified MAC addresses,
1.1.1.2 ! misho 368: and furthermore it gives dnsmasq permission to summarily abandon a
1.1 misho 369: lease to one of the MAC addresses if another one comes along. Note
370: that this will work fine only as longer as only one interface is
371: up at any time. There is no way for dnsmasq to enforce this
372: constraint: if you configure multiple MAC addresses and violate
373: this rule, bad things will happen.
374:
1.1.1.2 ! misho 375: Addendum-II: The link above is dead, the former contents of the link are:
! 376:
! 377: ------------------------------------------------------------------------------
! 378: How can I keep the same DHCP client reservation, if the MAC address changes?
! 379:
! 380: When you reserve an IP address for a DHCP client, you provide the
! 381: MAC address of the client's NIC.
! 382:
! 383: It is possible to use a custom identifier, which is sent as
! 384: option 61 in the client's DHCP Discover and Request packet.
! 385:
! 386: The DhcpClientIdentifier is a REG_DWORD value that is located at:
! 387:
! 388: Windows NT 4.0 SP2+
! 389:
! 390: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Adapter Name>'X'\Parameters\Tcpip
! 391:
! 392: where <Adapter Name> is the NIC driver name and 'X' is the number of the NIC.
! 393:
! 394: Windows 2000
! 395:
! 396: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TcpIp\Parameters\Interfaces\<NIC GUID>
! 397:
! 398: where <NIC GUID> is the GUID of the NIC.
! 399:
! 400: The valid range of data is 0x0 - 0xFFFFFFFF. The custom identifier is send as 4 bytes,
! 401: 8 hexadecimal character, in groups of 2 hexadecimal characters, with the groups being
! 402: sent in reverse order. If the custom identifier is less than 8 hexadeciaml characters,
! 403: it is zero padded at the end. Examples:
! 404:
! 405: Custom Client Client Reservation
! 406: Identifier on DHCP Server
! 407: 12345678 78563412
! 408: 123456 56341200
! 409: 1234 34120000
! 410: 1234567 67452301
! 411: 12345 45230100
! 412: 123 23010000
! 413: A18F42 428FA100
! 414: CF432 32F40C00
! 415: C32D1BE BED1320C
! 416:
! 417: -------------------------------------------------------------------------------------------------------
! 418:
! 419:
1.1 misho 420: Q: Can dnsmasq do DHCP on IP-alias interfaces?
421:
422: A: Yes, from version-2.21. The support is only available running under
423: Linux, on a kernel which provides the RT-netlink facility. All 2.4
424: and 2.6 kernels provide RT-netlink and it's an option in 2.2
425: kernels.
426:
427: If a physical interface has more than one IP address or aliases
428: with extra IP addresses, then any dhcp-ranges corresponding to
429: these addresses can be used for address allocation. So if an
430: interface has addresses 192.168.1.0/24 and 192.168.2.0/24 and there
431: are DHCP ranges 192.168.1.100-192.168.1.200 and
432: 192.168.2.100-192.168.2.200 then both ranges would be used for host
433: connected to the physical interface. A more typical use might be to
434: have one of the address-ranges as static-only, and have known
435: hosts allocated addresses on that subnet using dhcp-host options,
436: while anonymous hosts go on the other.
437:
438:
439: Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
440: to do a recursive query" and DNS stops working. What's going on?
441:
442: A: Probably the nameserver is an authoritative nameserver for a
443: particular domain, but is not configured to answer general DNS
444: queries for an arbitrary domain. It is not suitable for use by
445: dnsmasq as an upstream server and should be removed from the
446: configuration. Note that if you have more than one upstream
447: nameserver configured dnsmasq will load-balance across them and
448: it may be some time before dnsmasq gets around to using a
449: particular nameserver. This means that a particular configuration
450: may work for sometime with a broken upstream nameserver
451: configuration.
452:
453:
454: Q: Does the dnsmasq DHCP server probe addresses before allocating
455: them, as recommended in RFC2131?
456:
457: A: Yes, dynamically allocated IP addresses are checked by sending an
458: ICMP echo request (ping). If a reply is received, then dnsmasq
459: assumes that the address is in use, and attempts to allocate an
460: different address. The wait for a reply is between two and three
461: seconds. Because the DHCP server is not re-entrant, it cannot serve
462: other DHCP requests during this time. To avoid dropping requests,
463: the address probe may be skipped when dnsmasq is under heavy load.
464:
465:
466: Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
467: DHCP doesn't work. What's the problem?
468:
469: A: This a variant on the iptables problem. Explicit details on how to
470: proceed can be found at
471: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html
472:
473:
474: Q: I'm using dnsmasq on a machine with the shorewall firewall, and
475: DHCP doesn't work. What's the problem?
476:
477: A: This a variant on the iptables problem. Explicit details on how to
478: proceed can be found at
479: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html
480:
481:
482: Q: Dnsmasq fails to start up with a message about capabilities.
483: Why did that happen and what can do to fix it?
484:
485: A: Change your kernel configuration: either deselect CONFIG_SECURITY
486: _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can
487: remove the need to set capabilities by running dnsmasq as root.
488:
489:
490: Q: Where can I get .rpms Suitable for openSUSE/SLES?
491:
492: A: Dnsmasq is in openSUSE itself, and the latest releases are also
493: available at http://download.opensuse.org/repositories/network/
494:
495:
496: Q: Can I run dnsmasq in a Linux vserver?
497:
498: A: Yes, as a DNS server, dnsmasq will just work in a vserver.
499: To use dnsmasq's DHCP function you need to give the vserver
500: extra system capabilities. Please note that doing so will lesser
501: the overall security of your system. The capabilities
502: required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW
503: is required to do an ICMP "ping" check on newly allocated
504: addresses. If you don't need this check, you can disable it with
505: --no-ping and omit the NET_RAW capability.
506: Adding the capabilities is done by adding them, one per line, to
507: either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or
508: /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please
509: refer to the vserver documentation for more information).
510:
511:
512: Q: What's the problem with syslog and dnsmasq?
513:
514: A: In almost all cases: none. If you have the normal arrangement with
515: local daemons logging to a local syslog, which then writes to disk,
516: then there's never a problem. If you use network logging, then
517: there's a potential problem with deadlock: the syslog daemon will
518: do DNS lookups so that it can log the source of log messages,
519: these lookups will (depending on exact configuration) go through
520: dnsmasq, which also sends log messages. With bad timing, you can
521: arrive at a situation where syslog is waiting for dnsmasq, and
522: dnsmasq is waiting for syslog; they will both wait forever. This
523: problem is fixed from dnsmasq-2.39, which introduces asynchronous
524: logging: dnsmasq no longer waits for syslog and the deadlock is
525: broken. There is a remaining problem in 2.39, where "log-queries"
526: is in use. In this case most DNS queries generate two log lines, if
527: these go to a syslog which is doing a DNS lookup for each log line,
528: then those queries will in turn generate two more log lines, and a
529: chain reaction runaway will occur. To avoid this, use syslog-ng
530: and turn on syslog-ng's dns-cache function.
531:
532:
533: Q: DHCP doesn't work with windows Vista, but everything else is fine.
534:
535: A: The DHCP client on windows Vista (and possibly later versions)
536: demands that the DHCP server send replies as broadcasts. Most other
537: clients don't do this. The broadcasts are send to
538: 255.255.255.255. A badly configured firewall which blocks such
539: packets will show exactly these symptoms (Vista fails, others
540: work).
541:
542:
543: Q: DHCP doesn't work with windows 7 but everything else is fine.
544:
545: A: There seems to be a problem if Windows 7 doesn't get a value for
546: DHCP option 252 in DHCP packets it gets from the server. The
1.1.1.2 ! misho 547: symptoms have been variously reported as continual DHCPINFORM
1.1 misho 548: requests in an attempt to get an option-252, or even ignoring DHCP
549: offers completely (and failing to get an IP address) if there is no
550: option-252 supplied. DHCP option 252 is for WPAD, WWW Proxy
551: Auto Detection and if you don't want or need to use that, then
552: simplest fix seems to be to supply an empty option with:
553:
554: dhcp-option=252,"\n"
555:
556:
557:
558:
559:
560:
561:
562:
563:
564:
565:
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