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