]>
Commit | Line | Data |
---|---|---|
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 |