分类: LINUX
2010-06-18 01:16:12
Dnsmasq accepts DNS queries and either answers them from a small, local, cache or forwards them to a real, recursive, DNS server. It loads the contents of /etc/hosts so that local hostnames which do not appear in the global DNS can be resolved and also answers DNS queries for DHCP configured hosts.
The dnsmasq DHCP server supports static address assignments and multiple networks. It automatically sends a sensible default set of DHCP options, and can be configured to send any desired set of DHCP options, including vendor-encapsulated options. It includes a secure, read-only, TFTP server to allow net/PXE boot of DHCP hosts and also supports BOOTP.
Dnsmasq supports IPv6 for DNS, but not DHCP.
More specific domains take precendence over less specific domains, so: --server=/google.com/1.2.3.4 --server=//2.3.4.5 will send queries for *.google.com to 1.2.3.4, except *, which will go to 2.3.4.5
The special server address '#' means, "use the standard servers", so --server=/google.com/1.2.3.4 --server=//# will send queries for *.google.com to 1.2.3.4, except * which will be forwarded as usual.
Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. local is a synonym for server to make configuration files clearer in this case.
The optional string after the @ character tells dnsmasq how to set the source of the queries to this nameserver. It should be an ip-address, which should belong to the machine on which dnsmasq is running otherwise this server line will be logged and then ignored, or an interface name. If an interface name is given, then queries to the server will be forced via that interface; if an ip-address is given then the source address of the queries will be set to that address. The query-port flag is ignored for any servers which have a source address specified but the port may be specified directly as part of the source address. Forcing queries to an interface is not implemented on all platforms supported by dnsmasq.
The optional set:
The interface:
Addresses allocated like this are not constrained to be in the range given by the --dhcp-range option, but they must be in the same subnet as some valid dhcp-range. For subnets which don't need a pool of dynamically allocated addresses, use the "static" keyword in the dhcp-range declaration.
It is allowed to use client identifiers rather than hardware addresses to identify hosts by prefixing with 'id:'. Thus: --dhcp-host=id:01:02:03:04,..... refers to the host with client identifier 01:02:03:04. It is also allowed to specify the client ID as text, like this: --dhcp-host=id:clientidastext,.....
The special option id:* means "ignore any client-id and use MAC addresses only." This is useful when a client presents a client-id sometimes but not others.
If a name appears in /etc/hosts, the associated address can be allocated to a DHCP lease, but only if a --dhcp-host option specifying the name also exists. Only one hostname can be given in a dhcp-host option, but aliases are possible by using CNAMEs. (See --cname ).
The special keyword "ignore" tells dnsmasq to never offer a DHCP lease to a machine. The machine can be specified by hardware address, client ID or hostname, for instance --dhcp-host=00:20:e0:3b:13:af,ignore This is useful when there is another DHCP server on the network which should be used by some machines.
The set: Hardware addresses normally match any network (ARP) type, but it is possible to restrict them to a single ARP type by preceding them with the ARP-type (in HEX) and "-". so --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4 will only match a Token-Ring hardware address, since the ARP-address type for token ring is 6.
As a special case, it is possible to include more than one hardware address. eg: --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2 This allows an IP address to be associated with multiple hardware addresses, and gives dnsmasq permission to abandon a DHCP lease to one of the hardware addresses when another one asks for a lease. Beware that this is a dangerous thing to do, it will only work reliably if only one of the hardware addresses is active at any time and there is no way for dnsmasq to enforce this. It is, for instance, useful to allocate a stable IP address to a laptop which has both wired and wireless interfaces. Special processing is done on a text argument for option 119, to conform with RFC 3397. Text or dotted-quad IP addresses as arguments to option 120 are handled as per RFC 3361. Dotted-quad IP addresses which are followed by a slash and then a netmask size are encoded as described in RFC 3442.
Be careful: no checking is done that the correct type of data for the option number is sent, it is quite possible to persuade dnsmasq to generate illegal DHCP packets with injudicious use of this flag. When the value is a decimal number, dnsmasq must determine how large the data item is. It does this by examining the option number and/or the value, but can be overridden by appending a single letter flag as follows: b = one byte, s = two bytes, i = four bytes. This is mainly useful with encapsulated vendor class options (see below) where dnsmasq cannot determine data size from the option number. Option data which consists solely of periods and digits will be interpreted by dnsmasq as an IP address, and inserted into an option as such. To force a literal string, use quotes. For instance when using option 66 to send a literal IP address as TFTP server name, it is necessary to do --dhcp-option=66,"1.2.3.4"
Encapsulated Vendor-class options may also be specified using --dhcp-option: for instance --dhcp-option=vendor:PXEClient,1,0.0.0.0 sends the encapsulated vendor class-specific option "mftp-address=0.0.0.0" to any client whose vendor-class matches "PXEClient". The vendor-class matching is substring based (see --dhcp-vendorclass for details). If a vendor-class option (number 60) is sent by dnsmasq, then that is used for selecting encapsulated options in preference to any sent by the client. It is possible to omit the vendorclass completely; --dhcp-option=vendor:,1,0.0.0.0 in which case the encapsulated option is always sent.
Options may be encapsulated within other options: for instance --dhcp-option=encap:175, 190, iscsi-client0 will send option 175, within which is the option 190. If multiple options are given which are encapsulated with the same option number then they will be correctly combined into one encapsulated option. encap: and vendor: are may not both be set in the same dhcp-option.
The final variant on encapsulated options is "Vendor-Identifying Vendor Options" as specified by RFC3925. These are denoted like this: --dhcp-option=vi-encap:2, 10, text The number in the vi-encap: section is the IANA enterprise number used to identify this option.
The address 0.0.0.0 is not treated specially in encapsulated options. --dhcp-match=set:efi-ia32,option:client-arch,6
will set the tag "efi-ia32" if the the number 6 appears in the list of architectures sent by the client in option 93. (See RFC 4578 for details.) If the value is a string, substring matching is used.
The special form with vi-encap: This specifies a boot option which may appear in a PXE boot menu. Dnsmasq supports PXE "proxy-DHCP", in this case another DHCP server on the network is responsible for allocating IP addresses, and dnsmasq simply provides the information given in pxe-prompt and pxe-service to allow netbooting. This mode is enabled using the proxy keyword in dhcp-range. The environment is inherited from the invoker of dnsmasq, with some or all of the following variables added.
DNSMASQ_CLIENT_ID if the host provided a client-id.
DNSMASQ_DOMAIN if the fully-qualified domain name of the host is known, this is set to the domain part.
If the client provides vendor-class, hostname or user-class, these are provided in DNSMASQ_VENDOR_CLASS DNSMASQ_SUPPLIED_HOSTNAME and DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn variables, but only for "add" actions or "old" actions when a host resumes an existing lease, since these data are not held in dnsmasq's lease database.
If dnsmasq was compiled with HAVE_BROKEN_RTC, then the length of the lease (in seconds) is stored in DNSMASQ_LEASE_LENGTH, otherwise the time of lease expiry is stored in DNSMASQ_LEASE_EXPIRES. The number of seconds until lease expiry is always stored in DNSMASQ_TIME_REMAINING.
If a lease used to have a hostname, which is removed, an "old" event is generated with the new state of the lease, ie no name, and the former name is provided in the environment variable DNSMASQ_OLD_HOSTNAME.
DNSMASQ_INTERFACE stores the name of the interface on which the request arrived; this is not set for "old" actions when dnsmasq restarts.
DNSMASQ_RELAY_ADDRESS is set if the client used a DHCP relay to contact dnsmasq and the IP address of the relay is known.
DNSMASQ_TAGS contains all the tags set during the DHCP transaction, separated by spaces.
All file descriptors are closed except stdin, stdout and stderr which are open to /dev/null (except in debug mode).
The script is not invoked concurrently: at most one instance of the script is ever running (dnsmasq waits for an instance of script to exit before running the next). Changes to the lease database are which require the script to be invoked are queued awaiting exit of a running instance. If this queueing allows multiple state changes occur to a single lease before the script can be run then earlier states are discarded and the current state of that lease is reflected when the script finally runs.
At dnsmasq startup, the script will be invoked for all existing leases as they are read from the lease file. Expired leases will be called with "del" and others with "old". When dnsmasq receives a HUP signal, the script will be invoked for existing leases with an "old " event.
When it receives a SIGUSR1, dnsmasq writes statistics to the system log. It writes the cache size, the number of names which have had to removed from the cache before they expired in order to make room for new names and the total number of names that have been inserted into the cache. For each upstream server it gives the number of queries sent, and the number which resulted in an error. In --no-daemon mode or when full logging is enabled (-q), a complete dump of the contents of the cache is made.
When it receives SIGUSR2 and it is logging direct to a file (see --log-facility ) dnsmasq will close and reopen the log file. Note that during this operation, dnsmasq will not be running as root. When it first creates the logfile dnsmasq changes the ownership of the file to the non-root user it will run as. Logrotate should be configured to create a new log file with the ownership which matches the existing one before sending SIGUSR2. If TCP DNS queries are in progress, the old logfile will remain open in child processes which are handling TCP queries and may continue to be written. There is a limit of 150 seconds, after which all existing TCP processes will have expired: for this reason, it is not wise to configure logfile compression for logfiles which have just been rotated. Using logrotate, the required options are create and delaycompress.
Dnsmasq is a DNS query forwarder: it it not capable of recursively answering arbitrary queries starting from the root servers but forwards such queries to a fully recursive upstream DNS server which is typically provided by an ISP. By default, dnsmasq reads /etc/resolv.conf to discover the IP addresses of the upstream nameservers it should use, since the information is typically stored there. Unless --no-poll is used, dnsmasq checks the modification time of /etc/resolv.conf (or equivalent if --resolv-file is used) and re-reads it if it changes. This allows the DNS servers to be set dynamically by PPP or DHCP since both protocols provide the information. Absence of /etc/resolv.conf is not an error since it may not have been created before a PPP connection exists. Dnsmasq simply keeps checking in case /etc/resolv.conf is created at any time. Dnsmasq can be told to parse more than one resolv.conf file. This is useful on a laptop, where both PPP and DHCP may be used: dnsmasq can be set to poll both /etc/ppp/resolv.conf and /etc/dhcpc/resolv.conf and will use the contents of whichever changed last, giving automatic switching between DNS servers.
Upstream servers may also be specified on the command line or in the configuration file. These server specifications optionally take a domain name which tells dnsmasq to use that server only to find names in that particular domain.
In order to configure dnsmasq to act as cache for the host on which it is running, put "nameserver 127.0.0.1" in /etc/resolv.conf to force local processes to send queries to dnsmasq. Then either specify the upstream servers directly to dnsmasq using --server options or put their addresses real in another file, say /etc/resolv.dnsmasq and run dnsmasq with the -r /etc/resolv.dnsmasq option. This second technique allows for dynamic update of the server addresses by PPP or DHCP.
Addresses in /etc/hosts will "shadow" different addresses for the same names in the upstream DNS, so "mycompany.com 1.2.3.4" in /etc/hosts will ensure that queries for "mycompany.com" always return 1.2.3.4 even if queries in the upstream DNS would otherwise return a different address. There is one exception to this: if the upstream DNS contains a CNAME which points to a shadowed name, then looking up the CNAME through dnsmasq will result in the unshadowed address associated with the target of the CNAME. To work around this, add the CNAME to /etc/hosts so that the CNAME is shadowed too.
The tag system works as follows: For each DHCP request, dnsmasq collects a set of valid tags from active configuration lines which include set: Any configuration lines which includes one or more tag: Note that for dhcp-range both tag: This system evolved from an earlier, more limited one and for backward compatibility "net:" may be used instead of "tag:" and "set:" may be omitted. (Except in dhcp-host, where "net:" may be used instead of "set:".) For the same reason, '#' may be used instead of '!' to indicate NOT.
The DHCP server in dnsmasq will function as a BOOTP server also, provided that the MAC address and IP address for clients are given, either using dhcp-host configurations or in /etc/ethers , and a dhcp-range configuration option is present to activate the DHCP server on a particular network. (Setting --bootp-dynamic removes the need for static address mappings.) The filename parameter in a BOOTP request is used as a tag, as is the tag "bootp", allowing some control over the options returned to different classes of hosts.
dhcp-range may have an interface name supplied as "interface: Similarly, enable-tftp may take an interface name, which enables TFTP only for a particular interface, ignoring --interface or --listen-address flags. In addition --tftp-secure and --tftp-unique-root and --tftp-no-blocksize are ignored for requests from such interfaces. (A --tftp-root directive giving a root path and an interface should be provided too.)
These rules may seem odd at first sight, but they allow a single line of the form "dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" to be added to dnsmasq configuration which then supplies DHCP and DNS services to that interface, without affecting what services are supplied to other interfaces and irrespective of the existance or lack of "interface=
0 - Dnsmasq successfully forked into the background, or terminated normally if backgrounding is not enabled.
1 - A problem with configuration was detected.
2 - A problem with network access occurred (address in use, attempt to use privileged ports without permission).
3 - A problem occurred with a filesystem operation (missing file/directory, permissions).
4 - Memory allocation failure.
5 - Other miscellaneous problem.
11 or greater - a non zero return code was received from the lease-script process "init" call. The exit code from dnsmasq is the script's exit code with 10 added.
Dnsmasq is capable of handling DNS and DHCP for at least a thousand clients. The DHCP lease times should not be very short (less than one hour). The value of --dns-forward-max can be increased: start with it equal to the number of clients and increase if DNS seems slow. Note that DNS performance depends too on the performance of the upstream nameservers. The size of the DNS cache may be increased: the hard limit is 10000 names and the default (150) is very low. Sending SIGUSR1 to dnsmasq makes it log information which is useful for tuning the cache size. See the NOTES section for details.
The built-in TFTP server is capable of many simultaneous file transfers: the absolute limit is related to the number of file-handles allowed to a process and the ability of the select() system call to cope with large numbers of file handles. If the limit is set too high using --tftp-max it will be scaled down and the actual limit logged at start-up. Note that more transfers are possible when the same file is being sent than when each transfer sends a different file.
It is possible to use dnsmasq to block Web advertising by using a list of known banner-ad servers, all resolving to 127.0.0.1 or 0.0.0.0, in /etc/hosts or an additional hosts file. The list can be very long, dnsmasq has been tested successfully with one million names. That size file needs a 1GHz processor and about 60Mb of RAM.
/usr/local/etc/dnsmasq.conf
/etc/resolv.conf
/etc/hosts
/etc/ethers
/var/lib/misc/dnsmasq.leases
/var/db/dnsmasq.leases
/var/run/dnsmasq.pid
The idea is that such a line can be added automatically by libvirt or equivalent systems, without disturbing any manual configuration.
EXIT CODES
LIMITS
The default values for resource limits in dnsmasq are generally conservative, and appropriate for embedded router type devices with slow processors and limited memory. On more capable hardware, it is possible to increase the limits, and handle many more clients. The following applies to dnsmasq-2.37: earlier versions did not scale as well.
INTERNATIONALISATION
Dnsmasq can be compiled to support internationalisation. To do this, the make targets "all-i18n" and "install-i18n" should be used instead of the standard targets "all" and "install". When internationalisation is compiled in, dnsmasq will produce log messages in the local language and support internationalised domain names (IDN). Domain names in /etc/hosts, /etc/ethers and /etc/dnsmasq.conf which contain non-ASCII characters will be translated to the DNS-internal punycode representation. Note that dnsmasq determines both the language for messages and the assumed charset for configuration files from the LANG environment variable. This should be set to the system default value by the script which is responsible for starting dnsmasq. When editing the configuration files, be careful to do so using only the system-default locale and not user-specific one, since dnsmasq has no direct way of determining the charset in use, and must assume that it is the system default.
FILES
/etc/dnsmasq.conf
SEE ALSO
hosts(5), resolver(5)
AUTHOR
This manual page was written by Simon Kelley <>.
Index
This document was created by man2html, using the manual pages.
Time: 21:01:31 GMT, June 07, 2010
chinaunix网友2010-06-20 10:01:12
你好!博客狠棒cheapMBT Shoes on sale! MBT Shoes are the combination of quality and fashion. MBT Shoes are perfect for lovers of the outdoors, hikers, mountain climbers, campers, and nature enthusiasts. MBT Lami Shoe are perfect for the rugged and the casual. In fact, they are perfect for just about anyone an