Annotation of embedaddon/dnsmasq/FAQ, revision 1.1
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
! 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: 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
! 62: dosen't work: dnsmasq seems not to use the nameservers in the order
! 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.]
! 147: Versign run the .com and .net top-level-domains. They have just
! 148: changed the configuration of their servers so that unknown .com and
! 149: .net domains, instead of returning an error code NXDOMAIN, (no such
! 150: domain) return the address of a host at Versign which runs a web
! 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
! 153: suffering Versign brokeness by run a command like
! 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
! 159: different unlikely domains, just in case you picked a wierd one
! 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
! 183: ethernet interface. This is normally the adddress on the connected
! 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
! 208: /etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send
! 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:
! 239: Q: What are these strange "bind-interface" and "bind-dynamic" options?
! 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
! 243: to take into account some rather bizzare contraints and select the
! 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
! 255: ::). This allows it to recieve all the packets sent to the server on
! 256: the relevant port. Access control (--interface, --except-interface,
! 257: --listen-address, etc) is implemented by dnsmasq: it queries the
! 258: kernel to determine the interface on which a packet was recieved and
! 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
! 279: non-existent inferfaces. We will deal with these in order.
! 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:
! 300: A --interface specification for a non-existent interface is a fatal
! 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
! 316: freshmeat.net, and they allow you to subcribe to email alerts when
! 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:
! 323: A: See http://www.isc.org/files/auth.html - that's
! 324: for the ISC daemon, but the same applies to dnsmasq.
! 325:
! 326: Q: Why does my Gentoo box pause for a minute before getting a new
! 327: lease?
! 328:
! 329: A: Because when a Gentoo box shuts down, it releases its lease with
! 330: the server but remembers it on the client; this seems to be a
! 331: Gentoo-specific patch to dhcpcd. On restart it tries to renew
! 332: a lease which is long gone, as far as dnsmasq is concerned, and
! 333: dnsmasq ignores it until is times out and restarts the process.
! 334: To fix this, set the dhcp-authoritative flag in dnsmasq.
! 335:
! 336: Q: My laptop has two network interfaces, a wired one and a wireless
! 337: one. I never use both interfaces at the same time, and I'd like the
! 338: same IP and configuration to be used irrespective of which
! 339: interface is in use. How can I do that?
! 340:
! 341: A: By default, the identity of a machine is determined by using the
! 342: MAC address, which is associated with interface hardware. Once an
! 343: IP is bound to the MAC address of one interface, it cannot be
! 344: associated with another MAC address until after the DHCP lease
! 345: expires. The solution to this is to use a client-id as the machine
! 346: identity rather than the MAC address. If you arrange for the same
! 347: client-id to sent when either interface is in use, the DHCP server
! 348: will recognise the same machine, and use the same address. The
! 349: method for setting the client-id varies with DHCP client software,
! 350: dhcpcd uses the "-I" flag. Windows uses a registry setting,
! 351: see http://www.jsiinc.com/SUBF/TIP2800/rh2845.htm
! 352: Addendum:
! 353: From version 2.46, dnsmasq has a solution to this which doesn't
! 354: involve setting client-IDs. It's possible to put more than one MAC
! 355: address in a --dhcp-host configuration. This tells dnsmasq that it
! 356: should use the specified IP for any of the specified MAC addresses,
! 357: and furthermore it gives dnsmasq permission to sumarily abandon a
! 358: lease to one of the MAC addresses if another one comes along. Note
! 359: that this will work fine only as longer as only one interface is
! 360: up at any time. There is no way for dnsmasq to enforce this
! 361: constraint: if you configure multiple MAC addresses and violate
! 362: this rule, bad things will happen.
! 363:
! 364: Q: Can dnsmasq do DHCP on IP-alias interfaces?
! 365:
! 366: A: Yes, from version-2.21. The support is only available running under
! 367: Linux, on a kernel which provides the RT-netlink facility. All 2.4
! 368: and 2.6 kernels provide RT-netlink and it's an option in 2.2
! 369: kernels.
! 370:
! 371: If a physical interface has more than one IP address or aliases
! 372: with extra IP addresses, then any dhcp-ranges corresponding to
! 373: these addresses can be used for address allocation. So if an
! 374: interface has addresses 192.168.1.0/24 and 192.168.2.0/24 and there
! 375: are DHCP ranges 192.168.1.100-192.168.1.200 and
! 376: 192.168.2.100-192.168.2.200 then both ranges would be used for host
! 377: connected to the physical interface. A more typical use might be to
! 378: have one of the address-ranges as static-only, and have known
! 379: hosts allocated addresses on that subnet using dhcp-host options,
! 380: while anonymous hosts go on the other.
! 381:
! 382:
! 383: Q: Dnsmasq sometimes logs "nameserver xxx.xxx.xxx.xxx refused
! 384: to do a recursive query" and DNS stops working. What's going on?
! 385:
! 386: A: Probably the nameserver is an authoritative nameserver for a
! 387: particular domain, but is not configured to answer general DNS
! 388: queries for an arbitrary domain. It is not suitable for use by
! 389: dnsmasq as an upstream server and should be removed from the
! 390: configuration. Note that if you have more than one upstream
! 391: nameserver configured dnsmasq will load-balance across them and
! 392: it may be some time before dnsmasq gets around to using a
! 393: particular nameserver. This means that a particular configuration
! 394: may work for sometime with a broken upstream nameserver
! 395: configuration.
! 396:
! 397:
! 398: Q: Does the dnsmasq DHCP server probe addresses before allocating
! 399: them, as recommended in RFC2131?
! 400:
! 401: A: Yes, dynamically allocated IP addresses are checked by sending an
! 402: ICMP echo request (ping). If a reply is received, then dnsmasq
! 403: assumes that the address is in use, and attempts to allocate an
! 404: different address. The wait for a reply is between two and three
! 405: seconds. Because the DHCP server is not re-entrant, it cannot serve
! 406: other DHCP requests during this time. To avoid dropping requests,
! 407: the address probe may be skipped when dnsmasq is under heavy load.
! 408:
! 409:
! 410: Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
! 411: DHCP doesn't work. What's the problem?
! 412:
! 413: A: This a variant on the iptables problem. Explicit details on how to
! 414: proceed can be found at
! 415: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html
! 416:
! 417:
! 418: Q: I'm using dnsmasq on a machine with the shorewall firewall, and
! 419: DHCP doesn't work. What's the problem?
! 420:
! 421: A: This a variant on the iptables problem. Explicit details on how to
! 422: proceed can be found at
! 423: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2007q4/001764.html
! 424:
! 425:
! 426: Q: Dnsmasq fails to start up with a message about capabilities.
! 427: Why did that happen and what can do to fix it?
! 428:
! 429: A: Change your kernel configuration: either deselect CONFIG_SECURITY
! 430: _or_ select CONFIG_SECURITY_CAPABILITIES. Alternatively, you can
! 431: remove the need to set capabilities by running dnsmasq as root.
! 432:
! 433:
! 434: Q: Where can I get .rpms Suitable for openSUSE/SLES?
! 435:
! 436: A: Dnsmasq is in openSUSE itself, and the latest releases are also
! 437: available at http://download.opensuse.org/repositories/network/
! 438:
! 439:
! 440: Q: Can I run dnsmasq in a Linux vserver?
! 441:
! 442: A: Yes, as a DNS server, dnsmasq will just work in a vserver.
! 443: To use dnsmasq's DHCP function you need to give the vserver
! 444: extra system capabilities. Please note that doing so will lesser
! 445: the overall security of your system. The capabilities
! 446: required are NET_ADMIN and NET_RAW. NET_ADMIN is essential, NET_RAW
! 447: is required to do an ICMP "ping" check on newly allocated
! 448: addresses. If you don't need this check, you can disable it with
! 449: --no-ping and omit the NET_RAW capability.
! 450: Adding the capabilities is done by adding them, one per line, to
! 451: either /etc/vservers/<vservername>/ccapabilities for a 2.4 kernel or
! 452: /etc/vservers/<vservername>/bcapabilities for a 2.6 kernel (please
! 453: refer to the vserver documentation for more information).
! 454:
! 455:
! 456: Q: What's the problem with syslog and dnsmasq?
! 457:
! 458: A: In almost all cases: none. If you have the normal arrangement with
! 459: local daemons logging to a local syslog, which then writes to disk,
! 460: then there's never a problem. If you use network logging, then
! 461: there's a potential problem with deadlock: the syslog daemon will
! 462: do DNS lookups so that it can log the source of log messages,
! 463: these lookups will (depending on exact configuration) go through
! 464: dnsmasq, which also sends log messages. With bad timing, you can
! 465: arrive at a situation where syslog is waiting for dnsmasq, and
! 466: dnsmasq is waiting for syslog; they will both wait forever. This
! 467: problem is fixed from dnsmasq-2.39, which introduces asynchronous
! 468: logging: dnsmasq no longer waits for syslog and the deadlock is
! 469: broken. There is a remaining problem in 2.39, where "log-queries"
! 470: is in use. In this case most DNS queries generate two log lines, if
! 471: these go to a syslog which is doing a DNS lookup for each log line,
! 472: then those queries will in turn generate two more log lines, and a
! 473: chain reaction runaway will occur. To avoid this, use syslog-ng
! 474: and turn on syslog-ng's dns-cache function.
! 475:
! 476:
! 477: Q: DHCP doesn't work with windows Vista, but everything else is fine.
! 478:
! 479: A: The DHCP client on windows Vista (and possibly later versions)
! 480: demands that the DHCP server send replies as broadcasts. Most other
! 481: clients don't do this. The broadcasts are send to
! 482: 255.255.255.255. A badly configured firewall which blocks such
! 483: packets will show exactly these symptoms (Vista fails, others
! 484: work).
! 485:
! 486:
! 487: Q: DHCP doesn't work with windows 7 but everything else is fine.
! 488:
! 489: A: There seems to be a problem if Windows 7 doesn't get a value for
! 490: DHCP option 252 in DHCP packets it gets from the server. The
! 491: symtoms have beeen variously reported as continual DHCPINFORM
! 492: requests in an attempt to get an option-252, or even ignoring DHCP
! 493: offers completely (and failing to get an IP address) if there is no
! 494: option-252 supplied. DHCP option 252 is for WPAD, WWW Proxy
! 495: Auto Detection and if you don't want or need to use that, then
! 496: simplest fix seems to be to supply an empty option with:
! 497:
! 498: dhcp-option=252,"\n"
! 499:
! 500:
! 501:
! 502:
! 503:
! 504:
! 505:
! 506:
! 507:
! 508:
! 509:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to FAQ CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / dnsmasq