diff options
Diffstat (limited to 'FAQ')
| -rwxr-xr-x | FAQ | 471 |
1 files changed, 471 insertions, 0 deletions
@@ -0,0 +1,471 @@ +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 are 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. + + Second addendum: following the discovery of a security flaw in the + DNS protocol, dnsmasq from version 2.43 has changed behavior. It + now uses a new, randomly selected, port for each query. The old + default behaviour (use one port allocated by the OS) is available by + setting --query-port=0, and setting the query port to a positive + value is still works. You should think hard and know what you are + doing before using either of these options. + +Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify + that? + +A: Update: from version 2.10, it does. There are a few limitations: + data obtained via TCP is not cached, and source-address + or query-port specifications are ignored for TCP. + +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 MacOS X and Solaris. + There are start-up scripts for MacOS X Tiger and Panther + in /contrib. Dnsmasq will link with uclibc to provide small + binaries suitable for use in embedded systems such as + routers. (There's special code to support machines with flash + filesystems and no battery-backed RTC.) + If you encounter make errors with *BSD, try installing gmake from + ports and building dnsmasq with "make MAKE=gmake" + For other systems, try altering the settings in config.h. + +Q: My company's 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 + Note that the "bogus-priv" option take priority over this option, + so the above will not work when the bogus-priv option is set. + +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 some 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, or set a domain in + your DHCP server, see below fr Windows XP and Mac OS X). + 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 options. + +Q: How do I set the DNS domain in Windows XP or MacOS X (ref: previous + question)? + +A: for XP, Control Panel > Network Connections > { Connection to gateway / + DNS } > Properties > { Highlight TCP/IP } > Properties > Advanced > + DNS Tab > DNS suffix for this connection: + +A: for OS X, System Preferences > Network > {Connection to gateway / DNS } > + Search domains: + +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. + +Q: I'm running Debian, and my machines get an address fine with DHCP, + but their names are not appearing in the DNS. + +A: By default, none of the DHCP clients send the host-name when asking + for a lease. For most of the clients, you can set the host-name to + send with the "hostname" keyword in /etc/network/interfaces. (See + "man interfaces" for details.) That doesn't work for dhclient, were + you have to add something like "send host-name daisy" to + /etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send + the hostname by default. + +Q: I'm network booting my machines, and trying to give them static + DHCP-assigned addresses. The machine gets its correct address + whilst booting, but then the OS starts and it seems to get + allocated a different address. + +A: What is happening is this: The boot process sends a DHCP + request and gets allocated the static address corresponding to its + MAC address. The boot loader does not send a client-id. Then the OS + starts and repeats the DHCP process, but it it does send a + client-id. Dnsmasq cannot assume that the two requests are from the + same machine (since the client ID's don't match) and even though + the MAC address has a static allocation, that address is still in + use by the first incarnation of the machine (the one from the boot, + without a client ID.) dnsmasq therefore has to give the machine a + dynamic address from its pool. There are three ways to solve this: + (1) persuade your DHCP client not to send a client ID, or (2) set up + the static assignment to the client ID, not the MAC address. The + default client-id will be 01:<MAC address>, so change the dhcp-host + line from "dhcp-host=11:22:33:44:55:66,1.2.3.4" to + "dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4" or (3) tell dnsmasq to + ignore client IDs for a particular MAC address, like this: + dhcp-host=11:22:33:44:55:66,id:* + +Q: What network types are supported by the DHCP server? + +A: Ethernet (and 802.11 wireless) are supported on all platforms. On + Linux all network types (including FireWire) are supported. + +Q: What is this strange "bind-interface" option? + +A: The DNS spec says that the reply to a DNS query must come from the + same address it was sent to. The traditional way to write an UDP + server to do this is to find all of the addresses belonging to the + machine (ie all the interfaces on the machine) and then create a + socket for each interface which is bound to the address of the + interface. Then when a packet is sent to address A, it is received + on the socket bound to address A and when the reply is also sent + via that socket, the source address is set to A by the kernel and + everything works. This is the how dnsmasq works when + "bind-interfaces" is set, with the obvious extension that is misses + out creating sockets for some interfaces depending on the + --interface, --address and --except-interface flags. The + disadvantage of this approach is that it breaks if interfaces don't + exist or are not configured when the daemon starts and does the + socket creation step. In a hotplug-aware world this is a real + problem. + + The alternative approach is to have only one socket, which is bound + to the correct port and the wildcard IP address (0.0.0.0). That + socket will receive _all_ packets sent to port 53, no matter what + destination address they have. This solves the problem of + interfaces which are created or reconfigured after daemon + start-up. To make this work is more complicated because of the + "reply source address" problem. When a UDP packet is sent by a + socket bound to 0.0.0.0 its source address will be set to the + address of one of the machine's interfaces, but which one is not + determined and can vary depending on the OS being run. To get round + this it is neccessary to use a scary advanced API to determine the + address to which a query was sent, and force that to be the source + address in the reply. For IPv4 this stuff in non-portable and quite + often not even available (It's different between FreeBSD 5.x and + Linux, for instance, and FreeBSD 4.x, Linux 2.0.x and OpenBSD don't + have it at all.) Hence "bind-interfaces" has to always be available + as a fall back. For IPv6 the API is standard and universally + available. + + It could be argued that if the --interface or --address flags are + used then binding interfaces is more appropriate, but using + wildcard binding means that dnsmasq will quite happily start up + after being told to use interfaces which don't exist, but which are + created later. Wildcard binding breaks the scenario when dnsmasq is + listening on one interface and another server (most probably BIND) + is listening on another. It's not possible for BIND to bind to an + (address,port) pair when dnsmasq has bound (wildcard,port), hence + the ability to explicitly turn off wildcard binding. + +Q: Why doesn't Kerberos work/why can't I get sensible answers to + queries for SRV records. + +A: Probably because you have the "filterwin2k" option set. Note that + it was on by default in example configuration files included in + versions before 2.12, so you might have it set on without + realising. + +Q: Can I get email notification when a new version of dnsmasq is + released? + +A: Yes, new releases of dnsmasq are always announced through + freshmeat.net, and they allow you to subcribe to email alerts when + new versions of particular projects are released. New releases are + also announced in the dnsmasq-discuss mailing list, subscribe at + http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss + +Q: What does the dhcp-authoritative option do? + +A: See http://www.isc.org/index.pl?/sw/dhcp/authoritative.php - that's + for the ISC daemon, but the same applies to dnsmasq. + +Q: Why does my Gentoo box pause for a minute before getting a new + lease? + +A: Because when a Gentoo box shuts down, it releases its lease with + the server but remembers it on the client; this seems to be a + Gentoo-specific patch to dhcpcd. On restart it tries to renew + a lease which is long gone, as far as dnsmasq is concerned, and + dnsmasq ignores it until is times out and restarts the process. + To fix this, set the dhcp-authoritative flag in dnsmasq. + +Q: My laptop has two network interfaces, a wired one and a wireless + one. I never use both interfaces at the same time, and I'd like the + same IP and configuration to be used irrespective of which + interface is in use. How can I do that? + +A: By default, the identity of a machine is determined by using the + MAC address, which is associated with interface hardware. Once an + IP is bound to the MAC address of one interface, it cannot be + associated with another MAC address until after the DHCP lease + expires. The solution to this is to use a client-id as the machine + identity rather than the MAC address. If you arrange for the same + client-id to sent when either interface is in use, the DHCP server + will recognise the same machine, and use the same address. The + method for setting the client-id varies with DHCP client software, + dhcpcd uses the "-I" flag. Windows uses a registry setting, + see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm +Addendum: + From version 2.46, dnsmasq has a solution to this which doesn't + involve setting client-IDs. It's possible to put more than one MAC + address in a --dhcp-host configuration. This tells dnsmasq that it + should use the specified IP for any of the specified MAC addresses, + and furthermore it gives dnsmasq permission to sumarily abandon a + lease to one of the MAC addresses if another one comes along. Note + that this will work fine only as longer as only one interface is + up at any time. There is no way for dnsmasq to enforce this + constraint: if you configure multiple MAC addresses and violate + this rule, bad things will happen. + +Q: Can dnsmasq do DHCP on IP-alias interfaces? + +A: Yes, from version-2.21. The support is only available running under + Linux, on a kernel which provides the RT-netlink facility. All 2.4 + and 2.6 kernels provide RT-netlink and it's an option in 2.2 + kernels. + + If a physical interface has more than one IP address or aliases + with extra IP addresses, then any dhcp-ranges corresponding to + these addresses can be used for address allocation. So if an + interface has addresses 192.168.1.0/24 and 192.68.2.0/24 and there + are DHCP ranges 192.168.1.100-192.168.1.200 and + 192.168.2.100-192.168.2.200 then both ranges would be used for host + connected to the physical interface. A more typical use might be to + have one of the address-ranges as static-only, and have known + hosts allocated addresses on that subnet using dhcp-host options, + while anonymous hosts go on the other. + + +Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused + to do a recursive query" and DNS stops working. What's going on? + +A: Probably the nameserver is an authoritative nameserver for a + particular domain, but is not configured to answer general DNS + queries for an arbitrary domain. It is not suitable for use by + dnsmasq as an upstream server and should be removed from the + configuration. Note that if you have more than one upstream + nameserver configured dnsmasq will load-balance across them and + it may be some time before dnsmasq gets around to using a + particular nameserver. This means that a particular configuration + may work for sometime with a broken upstream nameserver + configuration. + + +Q: Does the dnsmasq DHCP server probe addresses before allocating + them, as recommended in RFC2131? + +A: Yes, dynmaically allocated IP addresses are checked by sending an + ICMP echo request (ping). If a reply is received, then dnsmasq + assumes that the address is in use, and attempts to allocate an + different address. The wait for a reply is between two and three + seconds. Because the DHCP server is not re-entrant, it cannot serve + other DHCP requests during this time. To avoid dropping requests, + the address probe may be skipped when dnsmasq is under heavy load. + + +Q: I'm using dnsmasq on a machine with the Firestarter firewall, and + DHCP doesn't work. What's the problem? + +A: This a variant on the iptables problem. Explicit details on how to + proceed can be found at + http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html + + +Q: I'm using dnsmasq on a machine with the shorewall firewall, and + DHCP doesn't work. What's the problem? + +A: This a variant on the iptables problem. Explicit details on how to + proceed can be found at + http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html + + +Q: Dnsmasq fails to start up with a message about capabilities. + Why did that happen and what can do to fix it? + +A: Change your kernel configuration: either deselect CONFIG_SECURITY + _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can + remove the need to set capabilities by running dnsmasq as root. + +Q: Where can I get .rpms Suitable for Suse? + +A: Dnsmasq is in Suse itself, and the latest releases are also + available at ftp://ftp.suse.com/pub/people/ug/ + + +Q: Can I run dnsmasq in a Linux vserver? + +A: Yes, as a DNS server, dnsmasq will just work in a vserver. + To use dnsmasq's DHCP function you need to give the vserver + extra system capabilities. Please note that doing so will lesser + the overall security of your system. The capabilities + required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW + is required to do an ICMP "ping" check on newly allocated + addresses. If you don't need this check, you can disable it with + --no-ping and omit the NET_RAW capability. + Adding the capabilities is done by adding them, one per line, to + either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or + /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please + refer to the vserver documentation for more information). + + +Q: What's the problem with syslog and dnsmasq? + +A: In almost all cases: none. If you have the normal arrangement with + local daemons logging to a local syslog, which then writes to disk, + then there's never a problem. If you use network logging, then + there's a potential problem with deadlock: the syslog daemon will + do DNS lookups so that it can log the source of log messages, + these lookups will (depending on exact configuration) go through + dnsmasq, which also sends log messages. With bad timing, you can + arrive at a situation where syslog is waiting for dnsmasq, and + dnsmasq is waiting for syslog; they will both wait forever. This + problem is fixed from dnsmasq-2.39, which introduces asynchronous + logging: dnsmasq no longer waits for syslog and the deadlock is + broken. There is a remaining problem in 2.39, where "log-queries" + is in use. In this case most DNS queries generate two log lines, if + these go to a syslog which is doing a DNS lookup for each log line, + then those queries will in turn generate two more log lines, and a + chain reaction runaway will occur. To avoid this, use syslog-ng + and turn on syslog-ng's dns-cache function. + + + + + + + + + + + + + + + |