Annotation of embedaddon/dnsmasq/FAQ, revision 1.1.1.3

1.1       misho       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
1.1.1.2   misho      12:    port: queries are dropped. The replies must be to outstanding queries
1.1       misho      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
1.1.1.2   misho      62:    doesn't work: dnsmasq seems not to use the nameservers in the order
1.1       misho      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.]
1.1.1.2   misho     147:    Verisign run the .com and .net top-level-domains. They have just
1.1       misho     148:    changed the configuration of their servers so that unknown .com and
                    149:    .net domains, instead of returning an error code NXDOMAIN, (no such
1.1.1.2   misho     150:    domain) return the address of a host at Verisign which runs a web
1.1       misho     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
1.1.1.2   misho     153:    suffering Verisign brokenness by run a command like 
1.1       misho     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
1.1.1.2   misho     159:    different unlikely domains, just in case you picked a weird one
1.1       misho     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
1.1.1.2   misho     183:    ethernet interface. This is normally the address on the connected
1.1       misho     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
1.1.1.2   misho     208:    /etc/dhclient.conf [Update: the latest dhcpcd packages _do_ send
1.1       misho     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: 
1.1.1.3 ! misho     239: Q: What are these strange "bind-interfaces" and "bind-dynamic" options?
1.1       misho     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
1.1.1.2   misho     243:    to take into account some rather bizarre constraints and select the
1.1       misho     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
1.1.1.2   misho     255:    ::). This allows it to receive all the packets sent to the server on
1.1       misho     256:    the relevant port. Access control (--interface, --except-interface,
                    257:    --listen-address, etc) is implemented by dnsmasq: it queries the
1.1.1.2   misho     258:    kernel to determine the interface on which a packet was received and
1.1       misho     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
1.1.1.2   misho     279:    non-existent interfaces. We will deal with these in order.
1.1       misho     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: 
1.1.1.2   misho     300:    An --interface specification for a non-existent interface is a fatal
1.1       misho     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
1.1.1.2   misho     316:    freshmeat.net, and they allow you to subscribe to email alerts when
1.1       misho     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: 
1.1.1.2   misho     323: A: The DHCP spec says that when a DHCP server receives a renewal request
                    324:    from a client it has no knowledge of, it should just ignore it.
                    325:    This is because it's supported to have more than one DHCP server
                    326:    on a network, and another DHCP server may be dealing with the client.
                    327:    This has the unfortunate effect that when _no_ DHCP replies to 
                    328:    the client, it takes some time for the client to time-out and start 
                    329:    to get a new lease. Setting this option makes dnsmasq violate the
                    330:    standard to the extent that it will send a NAK reply to the client, 
                    331:    causing it to immediately start to get a new lease. This improves 
                    332:    behaviour when machines move networks, and in the case that the DHCP
                    333:    lease database is lost. As long as there are not more tha one DHCP
                    334:    server on the network, it's safe to enable the option.
1.1       misho     335: 
                    336: Q: Why does my Gentoo box pause for a minute before getting a new
                    337:    lease?
                    338: 
                    339: A: Because when a Gentoo box shuts down, it releases its lease with
                    340:    the server but remembers it on the client; this seems to be a 
                    341:    Gentoo-specific patch to dhcpcd. On restart it tries to renew
                    342:    a lease which is long gone, as far as dnsmasq is concerned, and
                    343:    dnsmasq ignores it until is times out and restarts the process.
                    344:    To fix this, set the dhcp-authoritative flag in dnsmasq.
                    345: 
                    346: Q: My laptop has two network interfaces, a wired one and a wireless
                    347:    one. I never use both interfaces at the same time, and I'd like the
                    348:    same IP and configuration to be used irrespective of which
                    349:    interface is in use. How can I do that?
                    350: 
                    351: A: By default, the identity of a machine is determined by using the
                    352:    MAC address, which is associated with interface hardware. Once an
                    353:    IP is bound to the MAC address of one interface, it cannot be
                    354:    associated with another MAC address until after the DHCP lease
                    355:    expires. The solution to this is to use a client-id as the machine
                    356:    identity rather than the MAC address. If you arrange for the same
                    357:    client-id to sent when either interface is in use, the DHCP server
                    358:    will recognise the same machine, and use the same address. The
                    359:    method for setting the client-id varies with DHCP client software,
                    360:    dhcpcd uses the "-I" flag. Windows uses a registry setting,
                    361:    see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm
1.1.1.2   misho     362: 
1.1       misho     363: Addendum:
                    364:    From version 2.46, dnsmasq has a solution to this which doesn't
                    365:    involve setting client-IDs. It's possible to put more than one MAC
                    366:    address in a --dhcp-host configuration. This tells dnsmasq that it
                    367:    should use the specified IP for any of the specified MAC addresses,
1.1.1.2   misho     368:    and furthermore it gives dnsmasq permission to summarily abandon a
1.1       misho     369:    lease to one of the MAC addresses if another one comes along. Note
                    370:    that this will work fine only as longer as only one interface is
                    371:    up at any time. There is no way for dnsmasq to enforce this
                    372:    constraint: if you configure multiple MAC addresses and violate 
                    373:    this rule, bad things will happen.
                    374: 
1.1.1.2   misho     375: Addendum-II: The link above is dead, the former contents of the link are:
                    376: 
                    377: ------------------------------------------------------------------------------
                    378: How can I keep the same DHCP client reservation, if the MAC address changes?
                    379: 
                    380: When you reserve an IP address for a DHCP client, you provide the
                    381: MAC address of the client's NIC.
                    382: 
                    383: It is possible to use a custom identifier, which is sent as 
                    384: option 61 in the client's DHCP Discover and Request packet.
                    385: 
                    386: The DhcpClientIdentifier is a REG_DWORD value that is located at:
                    387: 
                    388: Windows NT 4.0 SP2+
                    389: 
                    390: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Adapter Name>'X'\Parameters\Tcpip
                    391: 
                    392: where <Adapter Name> is the NIC driver name and 'X' is the number of the NIC.
                    393: 
                    394: Windows 2000
                    395: 
                    396: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TcpIp\Parameters\Interfaces\<NIC GUID>
                    397: 
                    398: where <NIC GUID> is the GUID of the NIC.
                    399: 
                    400: The valid range of data is 0x0 - 0xFFFFFFFF. The custom identifier is send as 4 bytes, 
                    401: 8 hexadecimal character, in groups of 2 hexadecimal characters, with the groups being 
                    402: sent in reverse order. If the custom identifier is less than 8 hexadeciaml characters, 
                    403: it is zero padded at the end. Examples:
                    404: 
                    405: Custom Client                 Client Reservation
                    406: Identifier                    on DHCP Server
                    407: 12345678                      78563412
                    408: 123456                        56341200
                    409: 1234                          34120000
                    410: 1234567                       67452301
                    411: 12345                         45230100
                    412: 123                           23010000
                    413: A18F42                        428FA100
                    414: CF432                         32F40C00
                    415: C32D1BE                       BED1320C
                    416: 
                    417: -------------------------------------------------------------------------------------------------------
                    418: 
                    419: 
1.1       misho     420: Q: Can dnsmasq do DHCP on IP-alias interfaces?
                    421: 
                    422: A: Yes, from version-2.21. The support is only available running under
                    423:    Linux, on a kernel which provides the RT-netlink facility. All 2.4 
                    424:    and 2.6 kernels provide RT-netlink and it's an option in 2.2
                    425:    kernels. 
                    426:    
                    427:    If a physical interface has more than one IP address or aliases
                    428:    with extra IP addresses, then any dhcp-ranges corresponding to
                    429:    these addresses can be used for address allocation. So if an
                    430:    interface has addresses 192.168.1.0/24 and 192.168.2.0/24 and there
                    431:    are DHCP ranges 192.168.1.100-192.168.1.200 and
                    432:    192.168.2.100-192.168.2.200 then both ranges would be used for host
                    433:    connected to the physical interface. A more typical use might be to
                    434:    have one of the address-ranges as static-only, and have known
                    435:    hosts allocated addresses on that subnet using dhcp-host options,
                    436:    while  anonymous hosts go on the other.
                    437: 
                    438: 
                    439: Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
                    440:    to do a recursive query" and DNS stops working. What's going on?
                    441: 
                    442: A: Probably the nameserver is an authoritative nameserver for a
                    443:    particular domain, but is not configured to answer general DNS
                    444:    queries for an arbitrary domain. It is not suitable for use by
                    445:    dnsmasq as an upstream server and should be removed from the
                    446:    configuration. Note that if you have more than one upstream
                    447:    nameserver configured dnsmasq will load-balance across them and
                    448:    it may be some time before dnsmasq gets around to using a 
                    449:    particular nameserver. This means that a particular configuration
                    450:    may work for sometime with a broken upstream nameserver
                    451:    configuration.
                    452: 
                    453: 
                    454: Q: Does the dnsmasq DHCP server probe addresses before allocating
                    455:    them, as recommended in RFC2131?
                    456: 
                    457: A: Yes, dynamically allocated IP addresses are checked by sending an
                    458:    ICMP echo request (ping). If a reply is received, then dnsmasq
                    459:    assumes that the address is in use, and attempts to allocate an
                    460:    different address. The wait for a reply is between two and three
                    461:    seconds. Because the DHCP server is not re-entrant, it cannot serve
                    462:    other DHCP requests during this time. To avoid dropping requests,
                    463:    the address probe may be skipped when dnsmasq is under heavy load.
                    464: 
                    465: 
                    466: Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
                    467:    DHCP doesn't work. What's the problem?
                    468: 
                    469: A: This a variant on the iptables problem. Explicit details on how to
                    470:    proceed can be found at 
                    471:    http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html
                    472:  
                    473: 
                    474: Q: I'm using dnsmasq on a machine with the shorewall firewall, and
                    475:    DHCP doesn't work. What's the problem?
                    476: 
                    477: A: This a variant on the iptables problem. Explicit details on how to
                    478:    proceed can be found at 
                    479:    http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html
                    480: 
                    481: 
                    482: Q: Dnsmasq fails to start up with a message about capabilities.
                    483:    Why did that happen and what can do to fix it?
                    484: 
                    485: A: Change your kernel configuration: either deselect CONFIG_SECURITY
                    486:    _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can 
                    487:    remove the need to set capabilities by running dnsmasq as root.
                    488: 
                    489: 
                    490: Q: Where can I get .rpms Suitable for openSUSE/SLES?
                    491: 
                    492: A: Dnsmasq is in openSUSE itself, and the latest releases are also
                    493:    available at http://download.opensuse.org/repositories/network/
                    494: 
                    495: 
                    496: Q: Can I run dnsmasq in a Linux vserver?
                    497: 
                    498: A: Yes, as a DNS server, dnsmasq will just work in a vserver.
                    499:    To use dnsmasq's DHCP function you need to give the vserver
                    500:    extra system capabilities. Please note that doing so will lesser 
                    501:    the overall security of your system. The capabilities 
                    502:    required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW
                    503:    is required to do an ICMP "ping" check on newly allocated
                    504:    addresses. If you don't need this check, you can disable it with
                    505:    --no-ping and omit the NET_RAW capability. 
                    506:    Adding the capabilities is done by adding them, one per line, to
                    507:    either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or
                    508:    /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please
                    509:    refer to the vserver documentation for more information).
                    510: 
                    511: 
                    512: Q: What's the problem with syslog and dnsmasq?
                    513: 
                    514: A: In almost all cases: none. If you have the normal arrangement with
                    515:    local daemons logging to a local syslog, which then writes to disk,
                    516:    then there's never a problem. If you use network logging, then
                    517:    there's a potential problem with deadlock: the syslog daemon will
                    518:    do DNS lookups so that it can log the source of log messages,
                    519:    these lookups will (depending on exact configuration) go through
                    520:    dnsmasq, which also sends log messages. With bad timing, you can 
                    521:    arrive at a situation where syslog is waiting for dnsmasq, and
                    522:    dnsmasq is waiting for syslog; they will both wait forever. This
                    523:    problem is fixed from dnsmasq-2.39, which introduces asynchronous
                    524:    logging: dnsmasq no longer waits for syslog and the deadlock is
                    525:    broken. There is a remaining problem in 2.39, where "log-queries"
                    526:    is in use. In this case most DNS queries generate two log lines, if
                    527:    these go to a syslog which is doing a DNS lookup for each log line,
                    528:    then those queries will in turn generate two more log lines, and a 
                    529:    chain reaction runaway will occur. To avoid this, use syslog-ng
                    530:    and turn on syslog-ng's dns-cache function.
                    531: 
                    532: 
                    533: Q: DHCP doesn't work with windows Vista, but everything else is fine.
                    534: 
                    535: A: The DHCP client on windows Vista (and possibly later versions)
                    536:    demands that the DHCP server send replies as broadcasts. Most other
                    537:    clients don't do this. The broadcasts are send to
                    538:    255.255.255.255. A badly configured firewall which blocks such
                    539:    packets will show exactly these symptoms (Vista fails, others
                    540:    work).
                    541: 
                    542:   
                    543: Q: DHCP doesn't work with windows 7 but everything else is fine.
                    544: 
                    545: A: There seems to be a problem if Windows 7 doesn't get a value for
                    546:    DHCP option 252 in DHCP packets it gets from the server. The
1.1.1.2   misho     547:    symptoms have been variously reported as continual DHCPINFORM
1.1       misho     548:    requests in an attempt to get an option-252, or even ignoring DHCP
                    549:    offers completely (and failing to get an IP address) if there is no
                    550:    option-252 supplied. DHCP option 252 is for WPAD, WWW Proxy 
                    551:    Auto Detection and if you don't want or need to use that, then 
                    552:    simplest fix seems to be to supply an empty option with:
                    553: 
                    554:    dhcp-option=252,"\n"
                    555: 
                    556: 
                    557: 
                    558:  
                    559: 
                    560: 
                    561: 
                    562: 
                    563:    
                    564: 
                    565:              

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>