]>
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 | ||
23 | A: Yes, they do, so technically dnsmasq is not RFC-compliant. In practice, the | |
24 | sorts of queries which dnsmasq is used for are always sent via UDP. Adding | |
25 | TCP support would make dnsmasq much more heavyweight for no practical | |
26 | benefit. If you really want to do zone transfers, forward port 53 TCP | |
27 | using in-kernel port-forwarding or a port-fowarder like rinetd. | |
28 | ||
29 | ||
30 | Q: When I send SIGUSR1 to dump the contents of the cache, some entries have | |
31 | no IP address and are for names like mymachine.mydomain.com.mydomain.com. | |
32 | What are these? | |
33 | ||
34 | A: They are negative entries: that's what the N flag means. Dnsmasq asked | |
35 | an upstream nameserver to resolve that address and it replied "doesn't | |
36 | exist, and won't exist for <n> hours" so dnsmasq saved that information so | |
37 | that if _it_ gets asked the same question it can answer directly without | |
38 | having to go back to the upstream server again. The strange repeated domains | |
39 | result from the way resolvers search short names. See "man resolv.conf" for | |
40 | details. | |
41 | ||
42 | ||
43 | Q: Will dnsmasq compile/run on non-Linux systems? | |
44 | ||
45 | A: Yes, there is explicit support for *BSD and Solaris. | |
46 | For other systems, try altering the settings in config.h. | |
47 | ||
48 | A: Update for V2. Doing DHCP is rather non-portable, so there may be | |
49 | a few teething troubles. The initial 2.0 release is known to work | |
50 | on Linux 2.2.x, Linux 2.4.x and Linux 2.6.x with uclibc and glibc | |
51 | 2.3. It also works on FreeBSD 4.8. The crucial problem is sending | |
52 | raw packets, bypassing the IP stack. Dnsmasq contains code to do | |
53 | using PF_PACKET sockets (which is for Linux) and the Berkeley packet | |
54 | filter (which works with BSD). If you are trying to port to another | |
55 | Un*x, bpf is the most likeley candidate. See config.h | |
56 | ||
57 | Q: My companies' nameserver knows about some names which aren't in the | |
58 | public DNS. Even though I put it first in /etc/resolv.conf, it | |
59 | dosen't work: dnsmasq seems not to use the nameservers in the order | |
60 | given. What am I doing wrong? | |
61 | ||
62 | A: By default, dnsmasq treats all the nameservers it knows about as | |
63 | equal: it picks the one to use using an algorithm designed to avoid | |
64 | nameservers which aren't responding. To make dnsmasq use the | |
65 | servers in order, give it the -o flag. If you want some queries | |
66 | sent to a special server, think about using the -S flag to give the | |
67 | IP address of that server, and telling dnsmasq exactly which | |
68 | domains to use the server for. | |
69 | ||
70 | Q: OK, I've got queries to a private nameserver working, now how about | |
71 | reverse queries for a range of IP addresses? | |
72 | ||
73 | A: Use the standard DNS convention of <reversed address>.in-addr.arpa. | |
74 | For instance to send reverse queries on the range 192.168.0.0 to | |
75 | 192.168.0.255 to a nameserver at 10.0.0.1 do | |
76 | server=/0.168.192.in-addr.arpa/10.0.0.1 | |
77 | ||
78 | Q: Dnsmasq fails to start with an error like this: "dnsmasq: bind | |
79 | failed: Cannot assign requested address". What's the problem? | |
80 | ||
81 | A: This has been seen when a system is bringing up a PPP interface at | |
82 | boot time: by the time dnsmasq start the interface has been | |
83 | created, but not brought up and assigned an address. The easiest | |
84 | solution is to use --interface flags to specify which interfaces | |
85 | dnsmasq should listen on. Since you are unlikely to want dnsmasq to | |
86 | listen on a PPP interface and offer DNS service to the world, the | |
87 | problem is solved. | |
88 | ||
89 | Q: I'm running on BSD and dnsmasq won't accept long options on the | |
90 | command line. | |
91 | ||
92 | A: Dnsmasq when built on BSD systems doesn't use GNU getopt by | |
93 | default. You can either just use the single-letter options or | |
94 | change config.h and the Makefile to use getopt-long. Note that | |
95 | options in /etc/dnsmasq.conf must always be the long form, | |
96 | on all platforms. | |
97 | ||
98 | Q: Names on the internet are working fine, but looking up local names | |
99 | from /etc/hosts or DHCP doesn't seem to work. | |
100 | ||
101 | A: Resolver code sometime does strange things when given names without | |
102 | any dots in. Win2k and WinXP may not use the DNS at all and just | |
103 | try and look up the name using WINS. On unix look at "options ndots:" | |
104 | in "man resolv.conf" for details on this topic. Testing lookups | |
105 | using "nslookup" or "dig" will work, but then attempting to run | |
106 | "ping" will get a lookup failure, appending a dot to the end of the | |
107 | hostname will fix things. (ie "ping myhost" fails, but "ping | |
108 | myhost." works. The solution is to make sure that all your hosts | |
109 | have a domain set ("domain" in resolv.conf, the network applet in | |
110 | windows, or set a domain in your DHCP server). Any domain will do, | |
111 | but "localnet" is traditional. Now when you resolve "myhost" the | |
112 | resolver will attempt to look up "myhost.localnet" so you need to | |
113 | have dnsmasq reply to that name. The way to do that is to include | |
114 | the domain in each name on /etc/hosts and/or to use the | |
115 | --expand-hosts and --domain-suffix options. | |
116 | ||
117 | Q: Can I get dnsmasq to save the contents of its cache to disk when | |
118 | I shut my machine down and re-load when it starts again. | |
119 | ||
120 | A: No, that facility is not provided. Very few names in the DNS have | |
121 | their time-to-live set for longer than a few hours so most of the | |
122 | cache entries would have expired after a shutdown. For longer-lived | |
123 | names it's much cheaper to just reload them from the upstream | |
124 | server. Note that dnsmasq is not shut down between PPP sessions so | |
125 | go off-line and then on-line again will not lose the contents of | |
126 | the cache. | |
127 | ||
128 | Q: Who are Verisign, what do they have to do with the bogus-nxdomain | |
129 | option in dnsmasq and why should I wory about it? | |
130 | ||
131 | A: [note: this was written in September 2003, things may well change.] | |
132 | Versign run the .com and .net top-level-domains. They have just | |
133 | changed the configuration of their servers so that unknown .com and | |
134 | .net domains, instead of returning an error code NXDOMAIN, (no such | |
135 | domain) return the address of a host at Versign which runs a web | |
136 | server showing a search page. Most right-thinking people regard | |
137 | this new behaviour as broken :-). You can test to see if you are | |
138 | suffering Versign brokeness by run a command like | |
139 | ||
140 | host jlsdajkdalld.com | |
141 | ||
142 | If you get "jlsdajkdalld.com" does not exist, then all is fine, if | |
143 | host returns an IP address, then the DNS is broken. (Try a few | |
144 | different unlikely domains, just in case you picked a wierd one | |
145 | which really _is_ registered.) | |
146 | ||
147 | Assuming that your DNS is broken, and you want to fix it, simply | |
148 | note the IP address being returned and pass it to dnsmasq using the | |
149 | --bogus-nxdomain flag. Dnsmasq will check for results returning | |
150 | that address and substitute an NXDOMAIN instead. | |
151 | ||
152 | As of writing, the IP address in question for the .com and .net | |
153 | domains is is 64.94.110.11. Various other, less prominent, | |
154 | registries pull the same stunt; there is a list of them all, and | |
155 | the addresses to block, at http://winware.org/bogus-domains.txt | |
156 | ||
1ab84e2f SK |
157 | Q: This new DHCP server is well and good, but it doesn't work for me. |
158 | What's the problem? | |
159 | ||
160 | A: There are a couple of configuration gotchas which have been | |
161 | encountered by people moving from the ISC dhcpd to the dnsmasq | |
162 | integrated DHCP daemon. Both are related to differences in | |
163 | in the way the two daemons bypass the IP stack to do "ground up" | |
164 | IP configuration and can lead to the dnsmasq daemon failing | |
165 | whilst the ISC one works. | |
166 | ||
167 | The first thing to check is the broadcast address set for the | |
168 | ethernet interface. This is normally the adddress on the connected | |
169 | network with all ones in the host part. For instance if the | |
170 | address of the ethernet interface is 192.168.55.7 and the netmask | |
171 | is 255.255.255.0 then the broadcast address should be | |
172 | 192.168.55.255. Having a broadcast address which is not on the | |
173 | network to which the interface is connected kills things stone | |
174 | dead. | |
175 | ||
176 | The second potential problem relates to firewall rules: since the ISC | |
177 | daemon in some configurations bypasses the kernel firewall rules | |
178 | entirely, the ability to run the ISC daemon does not indicate | |
179 | that the current configuration is OK for the dnsmasq daemon. | |
180 | For the dnsmasq daemon to operate it's vital that UDP packets to | |
181 | and from ports 67 and 68 and broadcast packets with source | |
182 | address 0.0.0.0 and destination address 255.255.255.255 are not | |
183 | dropped by iptables/ipchains. | |
184 | ||
9e4abcb5 SK |
185 | |
186 | ||
187 | ||
188 | ||
189 |