]>
Commit | Line | Data |
---|---|---|
9e4abcb5 SK |
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 is 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 | Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify | |
21 | that? | |
22 | ||
feba5c1d | 23 | A: Update: from version 2.10, it does. There are a few limitations: |
0a852541 | 24 | data obtained via TCP is not cached, and source-address |
feba5c1d | 25 | or query-port specifications are ignored for TCP. |
9e4abcb5 SK |
26 | |
27 | Q: When I send SIGUSR1 to dump the contents of the cache, some entries have | |
28 | no IP address and are for names like mymachine.mydomain.com.mydomain.com. | |
29 | What are these? | |
30 | ||
31 | A: They are negative entries: that's what the N flag means. Dnsmasq asked | |
32 | an upstream nameserver to resolve that address and it replied "doesn't | |
33 | exist, and won't exist for <n> hours" so dnsmasq saved that information so | |
34 | that if _it_ gets asked the same question it can answer directly without | |
35 | having to go back to the upstream server again. The strange repeated domains | |
36 | result from the way resolvers search short names. See "man resolv.conf" for | |
37 | details. | |
38 | ||
39 | ||
40 | Q: Will dnsmasq compile/run on non-Linux systems? | |
41 | ||
3d8df260 SK |
42 | A: Yes, there is explicit support for *BSD and MacOS X. There are |
43 | start-up scripts for MacOS X Tiger and Panther in /contrib. Earlier | |
44 | dnsmasq releases ran under Solaris, but that capability has | |
45 | probably rotted. Dnsmasq will link with uclibc to provide small | |
46 | binaries suitable for use in embedded systems such as | |
47 | routers. (There's special code to support machines with flash | |
48 | filesystems and no battery-backed RTC.) | |
9e4abcb5 | 49 | For other systems, try altering the settings in config.h. |
3d8df260 | 50 | |
9e4abcb5 SK |
51 | Q: My companies' nameserver knows about some names which aren't in the |
52 | public DNS. Even though I put it first in /etc/resolv.conf, it | |
53 | dosen't work: dnsmasq seems not to use the nameservers in the order | |
54 | given. What am I doing wrong? | |
55 | ||
56 | A: By default, dnsmasq treats all the nameservers it knows about as | |
57 | equal: it picks the one to use using an algorithm designed to avoid | |
58 | nameservers which aren't responding. To make dnsmasq use the | |
59 | servers in order, give it the -o flag. If you want some queries | |
60 | sent to a special server, think about using the -S flag to give the | |
61 | IP address of that server, and telling dnsmasq exactly which | |
62 | domains to use the server for. | |
63 | ||
64 | Q: OK, I've got queries to a private nameserver working, now how about | |
65 | reverse queries for a range of IP addresses? | |
66 | ||
67 | A: Use the standard DNS convention of <reversed address>.in-addr.arpa. | |
68 | For instance to send reverse queries on the range 192.168.0.0 to | |
69 | 192.168.0.255 to a nameserver at 10.0.0.1 do | |
70 | server=/0.168.192.in-addr.arpa/10.0.0.1 | |
feba5c1d SK |
71 | Note that the "bogus-priv" option take priority over this option, |
72 | so the above will not work when the bogus-priv option is set. | |
9e4abcb5 SK |
73 | |
74 | Q: Dnsmasq fails to start with an error like this: "dnsmasq: bind | |
75 | failed: Cannot assign requested address". What's the problem? | |
76 | ||
77 | A: This has been seen when a system is bringing up a PPP interface at | |
78 | boot time: by the time dnsmasq start the interface has been | |
79 | created, but not brought up and assigned an address. The easiest | |
80 | solution is to use --interface flags to specify which interfaces | |
81 | dnsmasq should listen on. Since you are unlikely to want dnsmasq to | |
82 | listen on a PPP interface and offer DNS service to the world, the | |
83 | problem is solved. | |
84 | ||
85 | Q: I'm running on BSD and dnsmasq won't accept long options on the | |
86 | command line. | |
87 | ||
3d8df260 | 88 | A: Dnsmasq when built on some BSD systems doesn't use GNU getopt by |
9e4abcb5 SK |
89 | default. You can either just use the single-letter options or |
90 | change config.h and the Makefile to use getopt-long. Note that | |
91 | options in /etc/dnsmasq.conf must always be the long form, | |
92 | on all platforms. | |
93 | ||
94 | Q: Names on the internet are working fine, but looking up local names | |
95 | from /etc/hosts or DHCP doesn't seem to work. | |
96 | ||
97 | A: Resolver code sometime does strange things when given names without | |
98 | any dots in. Win2k and WinXP may not use the DNS at all and just | |
99 | try and look up the name using WINS. On unix look at "options ndots:" | |
100 | in "man resolv.conf" for details on this topic. Testing lookups | |
101 | using "nslookup" or "dig" will work, but then attempting to run | |
102 | "ping" will get a lookup failure, appending a dot to the end of the | |
103 | hostname will fix things. (ie "ping myhost" fails, but "ping | |
104 | myhost." works. The solution is to make sure that all your hosts | |
3d8df260 SK |
105 | have a domain set ("domain" in resolv.conf, or set a domain in |
106 | your DHCP server, see below fr Windows XP and Mac OS X). | |
107 | Any domain will do, but "localnet" is traditional. Now when you | |
108 | resolve "myhost" the resolver will attempt to look up | |
109 | "myhost.localnet" so you need to have dnsmasq reply to that name. | |
110 | The way to do that is to include the domain in each name on | |
111 | /etc/hosts and/or to use the --expand-hosts and --domain options. | |
112 | ||
113 | Q: How do I set the DNS domain in Windows XP or MacOS X (ref: previous | |
114 | question)? | |
115 | ||
116 | A: for XP, Control Panel > Network Connections > { Connection to gateway / | |
117 | DNS } > Properties > { Highlight TCP/IP } > Properties > Advanced > | |
118 | DNS Tab > DNS suffix for this connection: | |
119 | ||
120 | A: for OS X, System Preferences > Network > {Connection to gateway / DNS } > | |
121 | Search domains: | |
9e4abcb5 SK |
122 | |
123 | Q: Can I get dnsmasq to save the contents of its cache to disk when | |
bb01cb96 | 124 | I shut my machine down and re-load when it starts again? |
9e4abcb5 SK |
125 | |
126 | A: No, that facility is not provided. Very few names in the DNS have | |
127 | their time-to-live set for longer than a few hours so most of the | |
128 | cache entries would have expired after a shutdown. For longer-lived | |
129 | names it's much cheaper to just reload them from the upstream | |
130 | server. Note that dnsmasq is not shut down between PPP sessions so | |
131 | go off-line and then on-line again will not lose the contents of | |
132 | the cache. | |
133 | ||
134 | Q: Who are Verisign, what do they have to do with the bogus-nxdomain | |
135 | option in dnsmasq and why should I wory about it? | |
136 | ||
137 | A: [note: this was written in September 2003, things may well change.] | |
138 | Versign run the .com and .net top-level-domains. They have just | |
139 | changed the configuration of their servers so that unknown .com and | |
140 | .net domains, instead of returning an error code NXDOMAIN, (no such | |
141 | domain) return the address of a host at Versign which runs a web | |
142 | server showing a search page. Most right-thinking people regard | |
143 | this new behaviour as broken :-). You can test to see if you are | |
144 | suffering Versign brokeness by run a command like | |
145 | ||
146 | host jlsdajkdalld.com | |
147 | ||
148 | If you get "jlsdajkdalld.com" does not exist, then all is fine, if | |
149 | host returns an IP address, then the DNS is broken. (Try a few | |
150 | different unlikely domains, just in case you picked a wierd one | |
151 | which really _is_ registered.) | |
152 | ||
153 | Assuming that your DNS is broken, and you want to fix it, simply | |
154 | note the IP address being returned and pass it to dnsmasq using the | |
155 | --bogus-nxdomain flag. Dnsmasq will check for results returning | |
156 | that address and substitute an NXDOMAIN instead. | |
157 | ||
158 | As of writing, the IP address in question for the .com and .net | |
159 | domains is is 64.94.110.11. Various other, less prominent, | |
160 | registries pull the same stunt; there is a list of them all, and | |
161 | the addresses to block, at http://winware.org/bogus-domains.txt | |
162 | ||
1ab84e2f SK |
163 | Q: This new DHCP server is well and good, but it doesn't work for me. |
164 | What's the problem? | |
165 | ||
166 | A: There are a couple of configuration gotchas which have been | |
167 | encountered by people moving from the ISC dhcpd to the dnsmasq | |
168 | integrated DHCP daemon. Both are related to differences in | |
169 | in the way the two daemons bypass the IP stack to do "ground up" | |
170 | IP configuration and can lead to the dnsmasq daemon failing | |
171 | whilst the ISC one works. | |
172 | ||
173 | The first thing to check is the broadcast address set for the | |
174 | ethernet interface. This is normally the adddress on the connected | |
175 | network with all ones in the host part. For instance if the | |
176 | address of the ethernet interface is 192.168.55.7 and the netmask | |
177 | is 255.255.255.0 then the broadcast address should be | |
178 | 192.168.55.255. Having a broadcast address which is not on the | |
179 | network to which the interface is connected kills things stone | |
180 | dead. | |
181 | ||
182 | The second potential problem relates to firewall rules: since the ISC | |
183 | daemon in some configurations bypasses the kernel firewall rules | |
184 | entirely, the ability to run the ISC daemon does not indicate | |
185 | that the current configuration is OK for the dnsmasq daemon. | |
186 | For the dnsmasq daemon to operate it's vital that UDP packets to | |
187 | and from ports 67 and 68 and broadcast packets with source | |
188 | address 0.0.0.0 and destination address 255.255.255.255 are not | |
189 | dropped by iptables/ipchains. | |
33820b7e SK |
190 | |
191 | Q: I'm running Debian, and my machines get an address fine with DHCP, | |
192 | but their names are not appearing in the DNS. | |
193 | ||
194 | A: By default, none of the DHCP clients send the host-name when asking | |
195 | for a lease. For most of the clients, you can set the host-name to | |
196 | send with the "hostname" keyword in /etc/network/interfaces. (See | |
197 | "man interfaces" for details.) That doesn't work for dhclient, were | |
198 | you have to add something like "send host-name daisy" to | |
3be34541 SK |
199 | /etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send |
200 | the hostname by default. | |
33820b7e SK |
201 | |
202 | Q: I'm network booting my machines, and trying to give them static | |
203 | DHCP-assigned addresses. The machine gets its correct address | |
204 | whilst booting, but then the OS starts and it seems to get | |
205 | allocated a different address. | |
206 | ||
207 | A: What is happening is this: The boot process sends a DHCP | |
208 | request and gets allocated the static address corresponding to its | |
209 | MAC address. The boot loader does not send a client-id. Then the OS | |
210 | starts and repeats the DHCP process, but it it does send a | |
211 | client-id. Dnsmasq cannot assume that the two requests are from the | |
212 | same machine (since the client ID's don't match) and even though | |
213 | the MAC address has a static allocation, that address is still in | |
214 | use by the first incarnation of the machine (the one from the boot, | |
215 | without a client ID.) dnsmasq therefore has to give the machine a | |
de37951c | 216 | dynamic address from its pool. There are three ways to solve this: |
33820b7e SK |
217 | (1) persuade your DHCP client not to send a client ID, or (2) set up |
218 | the static assignment to the client ID, not the MAC address. The | |
219 | default client-id will be 01:<MAC address>, so change the dhcp-host | |
220 | line from "dhcp-host=11:22:33:44:55:66,1.2.3.4" to | |
de37951c SK |
221 | "dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4" or (3) tell dnsmasq to |
222 | ignore client IDs for a particular MAC address, like this: | |
223 | dhcp-host=11:22:33:44:55:66,id:* | |
33820b7e SK |
224 | |
225 | Q: What network types are supported by the DHCP server? | |
1ab84e2f | 226 | |
33820b7e SK |
227 | A: Ethernet (and 802.11 wireless) are supported on all platforms. On |
228 | Linux Token Ring is also supported. | |
9e4abcb5 | 229 | |
de37951c SK |
230 | Q: What is this strange "bind-interface" option? |
231 | ||
232 | A: The DNS spec says that the reply to a DNS query must come from the | |
233 | same address it was sent to. The traditional way to write an UDP | |
234 | server to do this is to find all of the addresses belonging to the | |
235 | machine (ie all the interfaces on the machine) and then create a | |
236 | socket for each interface which is bound to the address of the | |
237 | interface. Then when a packet is sent to address A, it is received | |
238 | on the socket bound to address A and when the reply is also sent | |
239 | via that socket, the source address is set to A by the kernel and | |
240 | everything works. This is the how dnsmasq works when | |
241 | "bind-interfaces" is set, with the obvious extension that is misses | |
242 | out creating sockets for some interfaces depending on the | |
243 | --interface, --address and --except-interface flags. The | |
244 | disadvantage of this approach is that it breaks if interfaces don't | |
245 | exist or are not configured when the daemon starts and does the | |
246 | socket creation step. In a hotplug-aware world this is a real | |
247 | problem. | |
248 | ||
249 | The alternative approach is to have only one socket, which is bound | |
250 | to the correct port and the wildcard IP address (0.0.0.0). That | |
251 | socket will receive _all_ packets sent to port 53, no matter what | |
252 | destination address they have. This solves the problem of | |
253 | interfaces which are created or reconfigured after daemon | |
254 | start-up. To make this work is more complicated because of the | |
255 | "reply source address" problem. When a UDP packet is sent by a | |
256 | socket bound to 0.0.0.0 its source address will be set to the | |
257 | address of one of the machine's interfaces, but which one is not | |
258 | determined and can vary depending on the OS being run. To get round | |
259 | this it is neccessary to use a scary advanced API to determine the | |
260 | address to which a query was sent, and force that to be the source | |
261 | address in the reply. For IPv4 this stuff in non-portable and quite | |
262 | often not even available (It's different between FreeBSD 5.x and | |
263 | Linux, for instance, and FreeBSD 4.x, Linux 2.0.x and OpenBSD don't | |
264 | have it at all.) Hence "bind-interfaces" has to always be available | |
265 | as a fall back. For IPv6 the API is standard and universally | |
266 | available. | |
267 | ||
268 | It could be argued that if the --interface or --address flags are | |
269 | used then binding interfaces is more appropriate, but using | |
270 | wildcard binding means that dnsmasq will quite happily start up | |
271 | after being told to use interfaces which don't exist, but which are | |
272 | created later. Wildcard binding breaks the scenario when dnsmasq is | |
273 | listening on one interface and another server (most probably BIND) | |
274 | is listening on another. It's not possible for BIND to bind to an | |
275 | (address,port) pair when dnsmasq has bound (wildcard,port), hence | |
276 | the ability to explicitly turn off wildcard binding. | |
9e4abcb5 | 277 | |
c1bb8504 SK |
278 | Q: Why doesn't Kerberos work/why can't I get sensible answers to |
279 | queries for SRV records. | |
9e4abcb5 | 280 | |
c1bb8504 SK |
281 | A: Probably because you have the "filterwin2k" option set. Note that |
282 | it was on by default in example configuration files included in | |
283 | versions before 2.12, so you might have it set on without | |
284 | realising. | |
285 | ||
3be34541 SK |
286 | Q: Can I get email notification when a new version of dnsmasq is |
287 | released? | |
288 | ||
289 | A: Yes, new releases of dnsmasq are always announced through | |
290 | freshmeat.net, and they allow you to subcribe to email alerts when | |
3d8df260 SK |
291 | new versions of particular projects are released. New releases are |
292 | also announced in the dnsmasq-discuss mailing list, subscribe at | |
293 | http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss | |
3be34541 | 294 | |
fd9fa481 SK |
295 | Q: What does the dhcp-authoritative option do? |
296 | ||
297 | A: See http://www.isc.org/index.pl?/sw/dhcp/authoritative.php - that's | |
298 | for the ISC daemon, but the same applies to dnsmasq. | |
299 | ||
300 | Q: Why does my Gentoo box pause for a minute before getting a new | |
301 | lease? | |
302 | ||
303 | A: Because when a Gentoo box shuts down, it releases its lease with | |
304 | the server but remembers it on the client; this seems to be a | |
305 | Gentoo-specific patch to dhcpcd. On restart it tries to renew | |
306 | a lease which is long gone, as far as dnsmasq is concerned, and | |
307 | dnsmasq ignores it until is times out and restarts the process. | |
308 | To fix this, set the dhcp-authoritative flag in dnsmasq. | |
309 | ||
bb01cb96 SK |
310 | Q: My laptop has two network interfaces, a wired one and a wireless |
311 | one. I never use both interfaces at the same time, and I'd like the | |
312 | same IP and configuration to be used irrespcetive of which | |
3d8df260 | 313 | interface is in use. How can I do that? |
bb01cb96 SK |
314 | |
315 | A: By default, the identity of a machine is determined by using the | |
316 | MAC address, which is associated with interface hardware. Once an | |
317 | IP is bound to the MAC address of one interface, it cannot be | |
318 | associated with another MAC address until after the DHCP lease | |
319 | expires. The solution to this is to use a client-id as the machine | |
320 | identity rather than the MAC address. If you arrange for the same | |
321 | client-id to sent when either interface is in use, the DHCP server | |
322 | will recognise the same machine, and use the same address. The | |
323 | method for setting the client-id varies with DHCP client software, | |
324 | dhcpcd uses the "-I" flag. Windows uses a registry setting, | |
325 | see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm | |
3be34541 | 326 | |
0a852541 SK |
327 | Q: Can dnsmasq do DHCP on IP-alias interfaces? |
328 | ||
329 | A: Yes, from version-2.21. The support is only available running under | |
330 | Linux, on a kernel which provides the RT-netlink facility. All 2.4 | |
331 | and 2.6 kernels provide RT-netlink and it's an option in 2.2 | |
3d8df260 | 332 | kernels. |
0a852541 SK |
333 | |
334 | If a physical interface has more than one IP address or aliases | |
335 | with extra IP addresses, then any dhcp-ranges corresponding to | |
3d8df260 | 336 | these addresses can be used for address allocation. So if an |
0a852541 SK |
337 | interface has addresses 192.168.1.0/24 and 192.68.2.0/24 and there |
338 | are DHCP ranges 192.168.1.100-192.168.1.200 and | |
339 | 192.168.2.100-192.168.2.200 then both ranges would be used for host | |
340 | connected to the physical interface. A more typical use might be to | |
341 | have one of the address-ranges as static-only, and have known | |
342 | hosts allocated addresses on that subnet using dhcp-host options, | |
343 | while anonymous hosts go on the other. | |
344 | ||
3d8df260 SK |
345 | |
346 | Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused | |
347 | to do a recursive query" and DNS stops working. What's going on? | |
348 | ||
349 | A: Probably the nameserver is an authoritative nameserver for a | |
350 | particular domain, but is not configured to answer general DNS | |
351 | queries for an arbitrary domain. It is not suitable for use by | |
352 | dnsmasq as an upstream server and should be removed from the | |
353 | configuration. Note that if you have more than one upstream | |
354 | nameserver configured dnsmasq will load-balance across them and | |
355 | it may be some time before dnsmasq gets around to using a | |
356 | particular nameserver. This means that a particular configuration | |
357 | may work for sometime with a broken upstream nameserver | |
358 | configuration. | |
359 | ||
0a852541 SK |
360 | |
361 | ||
362 | ||
363 | ||
364 | ||
365 | ||
c1bb8504 SK |
366 | |
367 |