Pi-Hole/dnsmasq
1
0
Fork 0
mirror of https://github.com/pi-hole/dnsmasq.git synced 2025-12-19 10:18:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

import of dnsmasq-2.53.tar.gz

Browse Source
This commit is contained in:
Simon Kelley
2010-06-03 19:42:45 +01:00
parent 316e2730ac
commit 8ef5ada238
34 changed files with 6223 additions and 4426 deletions
Download Patch File Download Diff File Expand all files Collapse all files

362
man/dnsmasq.8
View File

@@ -65,6 +65,12 @@ cache the reply. This option gives a default value for time-to-live
(in seconds) which dnsmasq uses to cache negative replies even in
the absence of an SOA record.
.TP
.B --max-ttl=<time>
Set a maximum TTL value that will be handed out to clients. The specified
maximum TTL will be given to clients instead of the true TTL value if it is
lower. The true TTL value is however kept in the cache to avoid flooding
the upstream DNS servers.
.TP
.B \-k, --keep-in-foreground
Do not go into the background at startup but otherwise run as
normal. This is intended for use when dnsmasq is run under daemontools
@@ -84,7 +90,8 @@ Set the facility to which dnsmasq will send syslog entries, this
defaults to DAEMON, and to LOCAL0 when debug mode is in operation. If
the facility given contains at least one '/' character, it is taken to
be a filename, and dnsmasq logs to the given file, instead of
syslog. (Errors whilst reading configuration will still go to syslog,
syslog. If the facility is '-' then dnsmasq logs to stderr.
(Errors whilst reading configuration will still go to syslog,
but all output from a successful startup, and all output whilst
running, will go exclusively to the file.) When logging to a file,
dnsmasq will close and reopen the file when it receives SIGUSR2. This
@@ -276,6 +283,17 @@ Reject (and log) addresses from upstream nameservers which are in the
private IP ranges. This blocks an attack where a browser behind a
firewall is used to probe machines on the local network.
.TP
.B --rebind-localhost-ok
Exempt 127.0.0.0/8 from rebinding checks. This address range is
returned by realtime black hole servers, so blocking it may disable
these services.
.TP
.B --rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]
Do not detect and block dns-rebind on queries to these domains. The
argument may be either a single domain, or multiple domains surrounded
by '/', like the --server syntax, eg.
.B --rebind-domain-ok=/domain1/domain2/domain3/
.TP
.B \-n, --no-poll
Don't poll /etc/resolv.conf for changes.
.TP
@@ -308,7 +326,19 @@ dots in them. A non-standard port may be specified as
part of the IP
address using a # character.
More than one -S flag is allowed, with
repeated domain or ipaddr parts as required.
repeated domain or ipaddr parts as required.
More specific domains take precendence over less specific domains, so:
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/2.3.4.5
will send queries for *.google.com to 1.2.3.4, except *www.google.com,
which will go to 2.3.4.5
The special server address '#' means, "use the standard servers", so
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/#
will send queries for *.google.com to 1.2.3.4, except *www.google.com which will
be forwarded as usual.
Also permitted is a -S
flag which gives a domain but no IP address; this tells dnsmasq that
@@ -426,7 +456,7 @@ Set the maximum number of concurrent DNS queries. The default value is
where this needs to be increased is when using web-server log file
resolvers, which can generate large numbers of concurrent queries.
.TP
.B \-F, --dhcp-range=[[net:]network-id,]<start-addr>,<end-addr>[,<netmask>[,<broadcast>]][,<lease time>]
.B \-F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<start-addr>,<end-addr>[,<netmask>[,<broadcast>]][,<lease time>]
Enable the DHCP server. Addresses will be given out from the range
<start-addr> to <end-addr> and from statically defined addresses given
in
@@ -442,10 +472,13 @@ networks on which the machine running dnsmasq has an interface) the
netmask is optional. It is, however, required for networks which
receive DHCP service via a relay agent. The broadcast address is
always optional. It is always
allowed to have more than one dhcp-range in a single subnet. The optional
network-id is a alphanumeric label which marks this network so that
allowed to have more than one dhcp-range in a single subnet.
The optional
.B set:<tag>
sets an alphanumeric label which marks this network so that
dhcp options may be specified on a per-network basis.
When it is prefixed with 'net:' then its meaning changes from setting
When it is prefixed with 'tag:' instead, then its meaning changes from setting
a tag to matching it. Only one tag may be set, but more than one tag may be matched.
The end address may be replaced by the keyword
.B static
@@ -462,8 +495,11 @@ subnet. (See
and
.B pxe-service
for details.)
The interface:<interface name> section is not normally used. See the
NOTES section for details of this.
.TP
.B \-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,net:<netid>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]
.B \-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<lease_time>][,ignore]
Specify per host parameters for the DHCP server. This allows a machine
with a particular hardware address to be always allocated the same
hostname, IP address and lease time. A hostname specified like this
@@ -478,9 +514,15 @@ an infinite DHCP lease.
.B --dhcp-host=lap,192.168.0.199
tells
dnsmasq to always allocate the machine lap the IP address
192.168.0.199. Addresses allocated like this are not constrained to be
in the range given by the --dhcp-range option, but they must be on the
network being served by the DHCP server. It is allowed to use client identifiers rather than
192.168.0.199.
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:
.B --dhcp-host=id:01:02:03:04,.....
refers to the host with client identifier 01:02:03:04. It is also
@@ -494,7 +536,14 @@ but not others.
If a name appears in /etc/hosts, the associated address can be
allocated to a DHCP lease, but only if a
.B --dhcp-host
option specifying the name also exists. The special keyword "ignore"
option specifying the name also exists. Only one hostname can be
given in a
.B dhcp-host
option, but aliases are possible by using CNAMEs. (See
.B --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
@@ -503,13 +552,15 @@ This is
useful when there is another DHCP server on the network which should
be used by some machines.
The net:<network-id> sets the network-id tag
The set:<tag> contruct sets the tag
whenever this dhcp-host directive is in use. This can be used to
selectively send DHCP options just for this host. When a host matches any
selectively send DHCP options just for this host. More than one tag
can be set in a dhcp-host directive (but not in other places where
"set:<tag>" is allowed). When a host matches any
dhcp-host directive (or one implied by /etc/ethers) then the special
network-id tag "known" is set. This allows dnsmasq to be configured to
tag "known" is set. This allows dnsmasq to be configured to
ignore requests from unknown machines using
.B --dhcp-ignore=#known
.B --dhcp-ignore=tag:!known
Ethernet addresses (but not client-ids) may have
wildcard bytes, so for example
.B --dhcp-host=00:20:e0:3b:13:*,ignore
@@ -563,7 +614,7 @@ have exactly the same effect as
options containing the same information. /etc/ethers is re-read when
dnsmasq receives SIGHUP.
.TP
.B \-O, --dhcp-option=[<network-id>,[<network-id>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<value>[,<value>]]
.B \-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<value>[,<value>]]
Specify different or extra options to DHCP clients. By default,
dnsmasq sends some standard options to DHCP clients, the netmask and
broadcast address are set to the same as the host running dnsmasq, and
@@ -586,8 +637,8 @@ or
The special address 0.0.0.0 is taken to mean "the address of the
machine running dnsmasq". Data types allowed are comma separated
dotted-quad IP addresses, a decimal number, colon-separated hex digits
and a text string. If the optional network-ids are given then
this option is only sent when all the network-ids are matched.
and a text string. If the optional tags are given then
this option is only sent when all the tags are matched.
Special processing is done on a text argument for option 119, to
conform with RFC 3397. Text or dotted-quad IP addresses as arguments
@@ -640,7 +691,7 @@ used to identify this option.
The address 0.0.0.0 is not treated specially in
encapsulated options.
.TP
.B --dhcp-option-force=[<network-id>,[<network-id>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
.B --dhcp-option-force=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
This works in exactly the same way as
.B --dhcp-option
except that the option will always be sent, even if the client does
@@ -655,20 +706,20 @@ DHCP options. This make extra space available in the DHCP packet for
options but can, rarely, confuse old or broken clients. This flag
forces "simple and safe" behaviour to avoid problems in such a case.
.TP
.B \-U, --dhcp-vendorclass=<network-id>,<vendor-class>
Map from a vendor-class string to a network id tag. Most DHCP clients provide a
.B \-U, --dhcp-vendorclass=set:<tag>,<vendor-class>
Map from a vendor-class string to a tag. Most DHCP clients provide a
"vendor class" which represents, in some sense, the type of host. This option
maps vendor classes to tags, so that DHCP options may be selectively delivered
to different classes of hosts. For example
.B dhcp-vendorclass=printers,Hewlett-Packard JetDirect
.B dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect
will allow options to be set only for HP printers like so:
.B --dhcp-option=printers,3,192.168.4.4
.B --dhcp-option=tag:printers,3,192.168.4.4
The vendor-class string is
substring matched against the vendor-class supplied by the client, to
allow fuzzy matching.
allow fuzzy matching. The set: prefix is optional but allowed for consistency.
.TP
.B \-j, --dhcp-userclass=<network-id>,<user-class>
Map from a user-class string to a network id tag (with substring
.B \-j, --dhcp-userclass=set:<tag>,<user-class>
Map from a user-class string to a tag (with substring
matching, like vendor classes). Most DHCP clients provide a
"user class" which is configurable. This option
maps user classes to tags, so that DHCP options may be selectively delivered
@@ -676,24 +727,41 @@ to different classes of hosts. It is possible, for instance to use
this to set a different printer server for hosts in the class
"accounts" than for hosts in the class "engineering".
.TP
.B \-4, --dhcp-mac=<network-id>,<MAC address>
Map from a MAC address to a network-id tag. The MAC address may include
.B \-4, --dhcp-mac=set:<tag>,<MAC address>
Map from a MAC address to a tag. The MAC address may include
wildcards. For example
.B --dhcp-mac=3com,01:34:23:*:*:*
.B --dhcp-mac=set:3com,01:34:23:*:*:*
will set the tag "3com" for any host whose MAC address matches the pattern.
.TP
.B --dhcp-circuitid=<network-id>,<circuit-id>, --dhcp-remoteid=<network-id>,<remote-id>
Map from RFC3046 relay agent options to network-id tags. This data may
.B --dhcp-circuitid=set:<tag>,<circuit-id>, --dhcp-remoteid=set:<tag>,<remote-id>
Map from RFC3046 relay agent options to tags. This data may
be provided by DHCP relay agents. The circuit-id or remote-id is
normally given as colon-separated hex, but is also allowed to be a
simple string. If an exact match is achieved between the circuit or
agent ID and one provided by a relay agent, the network-id tag is set.
agent ID and one provided by a relay agent, the tag is set.
.TP
.B --dhcp-subscrid=<network-id>,<subscriber-id>
Map from RFC3993 subscriber-id relay agent options to network-id tags.
.B --dhcp-subscrid=set:<tag>,<subscriber-id>
Map from RFC3993 subscriber-id relay agent options to tags.
.TP
.B --dhcp-match=<network-id>,<option number>|option:<option name>|vi-encap:<enterprise>[,<value>]
Without a value, set the network-id tag if the client sends a DHCP
.B --dhcp-proxy[=<ip addr>]......
A normal DHCP relay agent is only used to forward the initial parts of
a DHCP interaction to the DHCP server. Once a client is configured, it
communicates directly with the server. This is undesirable if the
relay agent is addding extra information to the DHCP packets, such as
that used by
.B dhcp-circuitid
and
.B dhcp-remoteid.
A full relay implementation can use the RFC 5107 serverid-override
option to force the DHCP server to use the relay as a full proxy, with all
packets passing through it. This flag provides an alternative method
of doing the same thing, for relays which don't support RFC
5107. Given alone, it manipulates the server-id for all interactions
via relays. If a list of IP addresses is given, only interactions via
relays at those addresses are affected.
.TP
.B --dhcp-match=set:<tag>,<option number>|option:<option name>|vi-encap:<enterprise>[,<value>]
Without a value, set the tag if the client sends a DHCP
option of the given number or name. When a value is given, set the tag only if
the option is sent and matches the value. The value may be of the form
"01:ff:*:02" in which case the value must match (apart from widcards)
@@ -703,7 +771,7 @@ value. The value may also be of the same form as in
in which case the option sent is treated as an array, and one element
must match, so
--dhcp-match=efi-ia32,option:client-arch,6
--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
@@ -711,41 +779,56 @@ details.) If the value is a string, substring matching is used.
The special form with vi-encap:<enterpise number> matches against
vendor-identifying vendor classes for the specified enterprise. Please
see RFC 3925 for more details of the rare and interesting beasts.
see RFC 3925 for more details of these rare and interesting beasts.
.TP
.B \-J, --dhcp-ignore=<network-id>[,<network-id>]
When all the given network-ids match the set of network-ids derived
from the net, host, vendor and user classes, ignore the host and do
.B --tag-if=set:<tag>[,set:<tag>[,tag:<tag>[,tag:<tag>]]]
Perform boolean operations on tags. Any tag appearing as set:<tag> is set if
all the tags which appear as tag:<tag> are set, (or unset when tag:!<tag> is used)
If no tag:<tag> appears set:<tag> tags are set unconditionally.
Any number of set: and tag: forms may appear, in any order.
Tag-if lines ares executed in order, so if the tag in tag:<tag> is a
tag set by another
.B tag-if,
the line which sets the tag must precede the one which tests it.
.TP
.B \-J, --dhcp-ignore=tag:<tag>[,tag:<tag>]
When all the given tags appear in the tag set ignore the host and do
not allocate it a DHCP lease.
.TP
.B --dhcp-ignore-names[=<network-id>[,<network-id>]]
When all the given network-ids match the set of network-ids derived
from the net, host, vendor and user classes, ignore any hostname
.B --dhcp-ignore-names[=tag:<tag>[,tag:<tag>]]
When all the given tags appear in the tag set, ignore any hostname
provided by the host. Note that, unlike dhcp-ignore, it is permissible
to supply no netid tags, in which case DHCP-client supplied hostnames
to supply no tags, in which case DHCP-client supplied hostnames
are always ignored, and DHCP hosts are added to the DNS using only
dhcp-host configuration in dnsmasq and the contents of /etc/hosts and
/etc/ethers.
.TP
.B --dhcp-broadcast=<network-id>[,<network-id>]
When all the given network-ids match the set of network-ids derived
from the net, host, vendor and user classes, always use broadcast to
communicate with the host when it is unconfigured. Most DHCP clients which
.B --dhcp-generate-names=tag:<tag>[,tag:<tag>]
Generate a name for DHCP clients which do not otherwise have one,
using the MAC address expressed in hex, seperated by dashes. Note that
if a host provides a name, it will be used by preference to this,
unless
.B --dhcp-ignore-names
is set.
.TP
.B --dhcp-broadcast[=tag:<tag>[,tag:<tag>]]
When all the given tags appear in the tag set, always use broadcast to
communicate with the host when it is unconfigured. It is permissible
to supply no tags, in which case this is unconditional. Most DHCP clients which
need broadcast replies set a flag in their requests so that this
happens automatically, some old BOOTP clients do not.
.TP
.B \-M, --dhcp-boot=[net:<network-id>,]<filename>,[<servername>[,<server address>]]
.B \-M, --dhcp-boot=[tag:<tag>,]<filename>,[<servername>[,<server address>]]
Set BOOTP options to be returned by the DHCP server. Server name and
address are optional: if not provided, the name is left empty, and the
address set to the address of the machine running dnsmasq. If dnsmasq
is providing a TFTP service (see
.B --enable-tftp
) then only the filename is required here to enable network booting.
If the optional network-id(s) are given,
they must match for this configuration to be sent. Note that
network-ids are prefixed by "net:" to distinguish them.
If the optional tag(s) are given,
they must match for this configuration to be sent.
.TP
.B --pxe-service=[net:<network-id>,]<CSA>,<menu text>[,<basename>|<bootservicetype>][,<server address>]
.B --pxe-service=[tag:<tag>,]<CSA>,<menu text>[,<basename>|<bootservicetype>][,<server address>]
Most uses of PXE boot-ROMS simply allow the PXE
system to obtain an IP address and then download the file specified by
.B dhcp-boot
@@ -773,7 +856,7 @@ If no boot service type or filename is provided (or a boot service type of 0 is
then the menu entry will abort the net boot procedure and
continue booting from local media.
.TP
.B --pxe-prompt=[net:<network-id>,]<prompt>[,<timeout>]
.B --pxe-prompt=[tag:<tag>,]<prompt>[,<timeout>]
Setting this provides a prompt to be displayed after PXE boot. If the
timeout is given then after the
timeout has elapsed with no keyboard input, the first available menu
@@ -799,7 +882,7 @@ keyword in
.TP
.B \-X, --dhcp-lease-max=<number>
Limits dnsmasq to the specified maximum number of DHCP leases. The
default is 150. This limit is to prevent DoS attacks from hosts which
default is 1000. This limit is to prevent DoS attacks from hosts which
create thousands of leases and use lots of memory in the dnsmasq
process.
.TP
@@ -836,14 +919,16 @@ tried. This flag disables this check. Use with caution.
.TP
.B --log-dhcp
Extra logging for DHCP: log all the options sent to DHCP clients and
the netid tags used to determine them.
the tags used to determine them.
.TP
.B \-l, --dhcp-leasefile=<path>
Use the specified file to store DHCP lease information.
.TP
.B \-6 --dhcp-script=<path>
Whenever a new DHCP lease is created, or an old one destroyed, the
executable specified by this option is run. The arguments to the process
executable specified by this option is run. <path>
must be an absolute pathname, no PATH search occurs.
The arguments to the process
are "add", "old" or "del", the MAC
address of the host, the IP address, and the hostname,
if known. "add" means a lease has been created, "del" means it has
@@ -854,39 +939,61 @@ If the MAC address is from a network type other than ethernet,
it will have the network type prepended, eg "06-01:23:45:67:89:ab" for
token ring. The process is run as root (assuming that dnsmasq was originally run as
root) even if dnsmasq is configured to change UID to an unprivileged user.
The environment is inherited from the invoker of dnsmasq, and if the
host provided a client-id, this is stored in the environment variable
DNSMASQ_CLIENT_ID. If the fully-qualified domain name of the host is
known, the domain part is stored in DNSMASQ_DOMAIN.
If the client provides vendor-class, hostname or user-class,
these are provided in DNSMASQ_VENDOR_CLASS
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
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
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
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 network-id tags set during the
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: if subsequent lease
changes occur, the script is not invoked again until any existing
invocation exits. At dnsmasq startup, the script will be invoked for
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". <path>
must be an absolute pathname, no PATH search occurs. When dnsmasq
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.
.TP
@@ -955,17 +1062,20 @@ without an address specified when
.B --dhcp-fqdn
is set.
.TP
.B --enable-tftp
.B --enable-tftp[=<interface>]
Enable the TFTP server function. This is deliberately limited to that
needed to net-boot a client. Only reading is allowed; the tsize and
blksize extensions are supported (tsize is only supported in octet mode).
blksize extensions are supported (tsize is only supported in octet
mode). See NOTES section for use of the interface argument.
.TP
.B --tftp-root=<directory>
.B --tftp-root=<directory>[,<interface>]
Look for files to transfer using TFTP relative to the given
directory. When this is set, TFTP paths which include ".." are
rejected, to stop clients getting outside the specified root.
Absolute paths (starting with /) are allowed, but they must be within
the tftp-root.
the tftp-root. If the optional interface argument is given, the
directory is only used for TFTP requests via that interface.
.TP
.B --tftp-unique-root
Add the IP address of the TFTP client as a path component on the end
@@ -1152,31 +1262,41 @@ the CNAME. To work around this, add the CNAME to /etc/hosts so that
the CNAME is shadowed too.
.PP
The network-id system works as follows: For each DHCP request, dnsmasq
collects a set of valid network-id tags, one from the
The tag system works as follows: For each DHCP request, dnsmasq
collects a set of valid tags from active configuration lines which
include set:<tag>, including one from the
.B dhcp-range
used to allocate the address, one from any matching
.B dhcp-host
(and "known" if a dhcp-host matches)
the tag "bootp" for BOOTP requests, a tag whose name is the
name if the interface on which the request arrived,
and possibly many from matching vendor classes and user
classes sent by the DHCP client. Any
The tag "bootp" is set for BOOTP requests, and a tag whose name is the
name of the interface on which the request arrived is also set.
Any configuration lines which includes one or more tag:<tag> contructs
will only be valid if all that tags are matched in the set derived
above. Typically this is dhcp-option.
.B dhcp-option
which has network-id tags will be used in preference to an untagged
which has tags will be used in preference to an untagged
.B dhcp-option,
provided that _all_ the tags match somewhere in the
set collected as described above. The prefix '#' on a tag means 'not'
so --dhcp=option=#purple,3,1.2.3.4 sends the option when the
network-id tag purple is not in the set of valid tags.
set collected as described above. The prefix '!' on a tag means 'not'
so --dhcp=option=tag:!purple,3,1.2.3.4 sends the option when the
tag purple is not in the set of valid tags. (If using this in a
command line rather than a configuration file, be sure to escape !,
which is a shell metacharacter)
.PP
If the network-id in a
Note that for
.B dhcp-range
is prefixed with 'net:' then its meaning changes from setting a
tag to matching it. Thus if there is more than dhcp-range on a subnet,
and one is tagged with a network-id which is set (for instance
from a vendorclass option) then hosts which set the netid tag will be
allocated addresses in the tagged range.
both tag:<tag> and set:<tag> are allowed, to both select the range in
use based on (eg) dhcp-host, and to affect the options sent, based on
the range selected.
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
.B dhcp-host,
where "net:" may be used instead of "set:".) For the same reason, '#'
may be used instead of '!' to indicate NOT.
.PP
The DHCP server in dnsmasq will function as a BOOTP server also,
provided that the MAC address and IP address for clients are given,
@@ -1189,11 +1309,56 @@ configurations or in
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 matched against netids in
.B dhcp-option
configurations, as is the tag "bootp", allowing some control over the options returned to
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.
.B dhcp-range
may have an interface name supplied as
"interface:<interface-name>". The semantics if this are as follows:
For DHCP, if any other dhcp-range exists _without_ an interface name,
then the interface name is ignored and and dnsmasq behaves as if the
interface parts did not exist, otherwise DHCP is only provided to
interfaces mentioned in dhcp-range
declarations. For DNS, if there are no
.B --interface
or
.B --listen-address
flags, behaviour is unchanged by the interface part. If either of
these flags are present, the interfaces mentioned in
dhcp-ranges are added to the set which get DNS service.
Similarly,
.B enable-tftp
may take an interface name, which enables TFTP only for a particular
interface, ignoring
.B --interface
or
.B --listen-address
flags. In addition
.B --tftp-secure
and
.B --tftp-unique-root
and
.B --tftp-no-blocksize
are ignored for requests from such interfaces. (A
.B --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=<interface>"
lines elsewhere in the dnsmasq configuration.
"enable-tftp=virt0" and "tftp-root=<root>,virt0" do the same job for TFTP.
The idea is
that such a line can be added automatically by libvirt
or equivalent systems, without disturbing any manual
configuration.
.SH EXIT CODES
.PP
0 - Dnsmasq successfully forked into the background, or terminated
@@ -1224,10 +1389,7 @@ following applies to dnsmasq-2.37: earlier versions did not scale as well.
.PP
Dnsmasq is capable of handling DNS and DHCP for at least a thousand
clients. Clearly to do this the value of
.B --dhcp-lease-max
must be increased,
and lease times should not be very short (less than one hour). The
clients. The DHCP lease times should not be very short (less than one hour). The
value of
.B --dns-forward-max
can be increased: start with it equal to

387
man/es/dnsmasq.8
View File

@@ -68,8 +68,14 @@ informaci
dnsmasq usa para hacer cach<63>. Si las respuestas de servidores upstream
omiten esta informaci<63>n, dnsmasq no mete la respuesta en el cach<63>.
Esta opci<63>n brinda un valor predeterminado para el time-to-live que
dnsmasq usa para meter respuestas en el cach<63> a<>n en la ausencia de
un expediente SOA.
dnsmasq usa para meter respuestas negativas en el cach<63> a<>n en la
ausencia de un expediente SOA.
.TP
.B --max-ttl=<tiempo>
Fijar un valor TTL (tiempo de vida) m<>ximo que ser<65> entregado a
clientes. El TTL m<>ximo especificado ser<65> otorgado a clientes en vez
del TTL verdadero si es menor. El valor TTL real es mantenido en el cach<63>
para prevenir la inundaci<63>n de los servidores DNS upstream.
.TP
.B \-k, --keep-in-foreground
No ir hacia el fondo al iniciar, pero aparte de eso ejecutar como
@@ -91,7 +97,8 @@ Fijar la facilidad a la cual dnsmasq deber
esto es DAEMON por predeterminado, y LOCAL0 cuando el modo debug est<73>
en operaci<63>n. Si la facilidad brindada contiene por lo menos un car<61>cter
"/", se trata como un nombre de archivo, y dnsmasq bitacorear<61> a dicho
archivo, en vez de syslog. (Errores durante la lectura de la configuraci<63>n
archivo, en vez de syslog. Si la facilidad es '-' entonces dnsmasq
bitacorea a stderr. (Errores durante la lectura de la configuraci<63>n
ir<EFBFBD>n a syslog todav<61>a, pero todo output desde un inicio exitoso, y todo
output mientras en ejecuci<63>n, ir<69> a este archivo exclusivamente.)
Al bitacorear a un archivo, dnsmasq cerrar<61> y reabrir<69> el archivo al
@@ -304,6 +311,17 @@ Denegar (y bitacorear) direcciones de servidores upstream que est
dentro de rangos IP privados. Esto bloquea un ataque donde un navegador
detr<EFBFBD>s de un firewall es usado para analizar m<>quinas en la red local.
.TP
.B --rebind-localhost-ok
Eximir a 127.0.0.0/8 de verificaciones de rebinding. Este rango de
direcciones es retornado por servidores de tiempo real tipo hoyo
negro, as<61> que bloquearlo puede deshabilitar estos servicios.
.TP
.B --rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]
No detectar y bloquear dns-rebind en b<>squedas a estos dominios. El
argumento puede ser o un dominio sencillo, o m<>ltiples dominios
rodeados por '/', como el syntax de --server, por ejemplo
.B --rebind-domain-ok=/dominio1/dominio2/dominio3/
.TP
.B \-n, --no-poll
No revisar periodicamente a /etc/resolv.conf en busca de cambios.
.TP
@@ -339,6 +357,20 @@ ser especificado como parte de la direcci
#. M<>s de una opci<63>n -S es permitida, con partes de dominio o
direcci<EFBFBD>n IP repetidas como sea necesario.
Dominios m<>s espec<65>ficos toman precedencia sobre los menos espec<65>ficos,
as<EFBFBD> que:
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/2.3.4.5
enviar<EFBFBD> b<>squedas por *.google.com hacia 1.2.3.4, excepto
*www.google.com, el cual ir<69> a 2.3.4.5.
La direcci<63>n especial de servidor '#' significa "usar los servidores
est<EFBFBD>ndares", as<61> que
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/#
enviar<EFBFBD> b<>squedas por *.google.com hacia 1.2.3.4, excepto
*www.google.com, el cual ser<65> reenviado de manera usual.
Tambi<EFBFBD>n se permite una opci<63>n -S la cual brinda un dominio pero
ninguna direcci<63>n IP; esto le dice a dnsmasq que un dominio es local
y puede responder a b<>squedas desde /etc/hosts o DHCP pero nunca
@@ -460,7 +492,7 @@ de casos. La
es al usar resolvedores de bit<69>coras de servidores web, los cuales pueden
generar un n<>mero inmenso de b<>squedas simult<6C>neas.
.TP
.B \-F, --dhcp-range=[[net:]network-id,]<direcci<63>n-inicio>,<direcci<63>n-final>[,<m<EFBFBD>scara>[,<broadcast>]][,<tiempo de arriendo>]
.B \-F, --dhcp-range=[interface:<interface>,][tag:<tag>[,tag:<tag>],][set:<tag],]<direcci<63>n-inicio>,<direcci<63>n-final>[,<netmask>[,<broadcast>]][,<tiempo de arriendo>]
Habilitar el servidor DHCP. Direcciones ser<65>n distribuidas desde el
rango <direcci<63>n-inicio> hasta <direcci<63>n-final> y desde direcciones definidas
est<EFBFBD>ticamente en opciones
@@ -477,10 +509,13 @@ cuales la m
m<EFBFBD>scara de subred es opcional. Pero, es requerida para redes que
reciben servicio DHCP v<>a un agente de relay. La direcci<63>n de
broadcast siempre es opcional. Siempre se permite tener m<>s de
un rango dhcp (dhcp-range) en una subred. El par<61>metro opcional
network-id es una etiqueta alfanum<75>rica la cual marca esta red de
un rango dhcp (dhcp-range) en una subred.
El par<61>metro opcional
.B set:<tag>
fija una etiqueta alfanum<75>rica la cual marca esta red de
tal forma que opciones dhcp puedan ser especificadas en base a cada red.
Cuando es prefijada con 'net:' entonces el significado cambia
Cuando es prefijada con 'tag:' en vez, entonces el significado cambia
de "fijar etiqueta" a "coincidir con etiqueta". Solo una etiqueta puede
ser fijada, pero m<>s de una puede ser revisada por coincidencias. La
direcci<EFBFBD>n final puede ser remplazada por la palabra clave
@@ -497,8 +532,11 @@ caso en el cual dnsmasq proveer
y
.B pxe-service
para detalles.)
La secci<63>n interface:<interface name> no es normalmente usada. Ver la
secci<EFBFBD>n NOTAS para detalles sobre esto.
.TP
.B \-G, --dhcp-host=[<direcci<EFBFBD>n de hardware>][,id:<client_id>|*][,net:<netid>][,<direcci<63>n IP>][,<nombre de host>][,<tiempo de arriendo>][,ignore]
.B \-G, --dhcp-host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][,<ipaddr>][,<hostname>][,<tiempo_de_arriendo>][,ignorar]
Especificar par<61>metros por host para el servidor DHCP. Esto permite
que una m<>quina con una direcci<63>n de hardware particular sea siempre
alocada el mismo nombre de host, direcci<63>n IP, y tiempo de arriendo.
@@ -513,10 +551,15 @@ le dice a dnsmasq que debe darle a la m
ethernet 00:20:e0:3b:13:af el nombre wap, y un arriendo DHCP infinito.
.B --dhcp-host=lap,192.168.0.199
le dice a dnsmasq que siempre debe alocarle a la maquina lap
la direcci<63>n IP 192.168.0.199. Direcciones alocadas de esta manera
no tienen que estar dentro del rango dado con la opci<63>n --dhcp-range,
pero deben estar en la red siendo servida por el servidor DHCP. Se
permite usar identificadores de clientes en vez de direcciones de
la direcci<63>n IP 192.168.0.199.
Direcciones alocadas de esta manera no tienen que estar dentro
del rango dado con la opci<63>n --dhcp-range, pero deben estar en la subred
de un rango DHCP (dhcp-range) v<>lido. Para subredes que no necesitan
una collecci<63>n de direcciones dinamicamente alocadas, usar la palabra
clave "static" in la declaraci<63>n dhcp-range.
Es permitido usar identificadores de cliente en vez de direcciones de
hardware para identificar hosts prefijando 'id:'. O sea que:
.B --dhcp-host=id:01:02:03:04,.....
se refiere al host con identificador de cliente 01:02:03:04.
@@ -530,7 +573,14 @@ presenta un ID de cliente algunas veces pero otras no.
Si un nombre aparece en /etc/hosts, la direcci<63>n asociada puede
ser alocada a un arriendo DHCP, pero solo si existe una opci<63>n
.B --dhcp-host
la cual especifica el nombre tambi<62>n. La palabra clave "ignore"
la cual especifica el nombre tambi<62>n. Solo un hostname puede ser
brindado en una opci<63>n
.B dhcp-host
pero aliases son posibles por medio del uso de CNAMEs. (Ver
.B --cname
).
La palabra clave "ignore"
le dice a dnsmasq que no debe ofrecer jam<61>s un arriendo DHCP a
una m<>quina. La m<>quina puede ser especificada por direcci<63>n de
hardware, ID de cliente, o nombre de host, por ejemplo:
@@ -538,14 +588,16 @@ hardware, ID de cliente, o nombre de host, por ejemplo:
Esto es <20>til cuando hay otro servidor DHCP en la red que debe ser
usado por alg<6C>nas m<>quinas.
El net:<network-id> fija la etiqueta network-id cuando sea que
El set:<tag> fija la etiqueta cuando sea que
esta directiva dhcp-host est<73> en uso. Esto puede ser usado para
enviar selectivamente opciones DHCP a este host. Cuando un host
coincide con cualquier directiva dhcp-host (o una implicada por
/etc/ethers) entonces la etiqueta network-id especial "known" es
enviar selectivamente opciones DHCP a este host. M<EFBFBD>s de una etiqueta
puede ser fijada en una directiva dhcp-host (pero no en otros lugares
donde "set:<tag>" es permitido). Cuando un host coincide con
cualquier directiva dhcp-host (o una implicada por
/etc/ethers) entonces la etiqueta especial "known" es
fijada. Esto permite que dnsmasq sea configurado para ignorar
pedidos desde m<>quinas desconocidas usando
.B --dhcp-ignore=#known
.B --dhcp-ignore=tag:!known
Direcciones ethernet (pero no client-ids) pueden tener bytes
comod<EFBFBD>nes, as<61> que por ejemplo
.B --dhcp-host=00:20:e0:3b:13:*,ignore
@@ -591,9 +643,10 @@ DHCP. El formato de /etc/ethers es una direcci
por ya sea un nombre de host o una direcci<63>n IP. Al ser leidas por
dnsmasq, estas l<>neas tienen ex<65>ctamente el mismo efecto que opciones
.B --dhcp-host
que contienen la misma informaci<63>n. /etc/ethers es re-le<6C>da cuando dnsmasq recibe un SIGHUP.
que contienen la misma informaci<63>n. /etc/ethers es re-le<6C>da cuando
dnsmasq recibe un SIGHUP.
.TP
.B \-O, --dhcp-option=[<network-id>,[<network-id>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<valor>[,<valor>]]
.B \-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>],[<value>[,<value>]]
Especificar opciones diferentes o extra a clientes DHCP. Por
predeterminado, dnsmasq env<6E>a algunas opciones est<73>ndar a clientes
DHCP. La m<>scara de subred y direcci<63>n broadcast son fijadas igual
@@ -618,9 +671,9 @@ o
La direcci<63>n especial 0.0.0.0 es entendida que significa "la
direcci<EFBFBD>n de la m<>quina que corre dnsmasq". Tipos de data permitidos
son direcciones IP de cuatro segmentos, un n<>mero decimal, d<>gitos hex
separados por colones, y un string de texto. Si las network-ids
separados por colones, y un string de texto. Si las etiquetas
opcionales son brindadas, entonces esta opci<63>n es solo enviada cuando
todas las network-ids coinciden.
todas las etiquetas coinciden.
Procesamiento especial es llevado a cabo en un argumento de texto para
la opci<63>n 119, en conforme con RFC3397. Direcciones IP textuales o de
@@ -672,7 +725,7 @@ para identificar esta opci
La direcci<63>n 0.0.0.0 no es tratada de forma especial en opciones encapsuladas.
.TP
.B --dhcp-option-force=[<network-id>,[<network-id>,]][encap:<opt>,][rfc3925-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<valor>[,<valor>]]
.B --dhcp-option-force=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
Esto funciona ex<65>ctamente de la misma forma que
.B --dhcp-option
excepto que la opci<63>n siempre ser<65> enviada, a<>n si el cliente no la pide en
@@ -687,20 +740,21 @@ hacia opciones DHCP. Esto crea espacio extra en el paquete DHCP para opciones,
pero puede raramente confundir clientes viejos o defectuosos. Esta opci<63>n forza
comportamiento "simple y sencillo" para prevenir problemas en tales casos.
.TP
.B \-U, --dhcp-vendorclass=<network-id>,<vendor-class>
Trazar desde un string vendor-class a un network id. La mayor<6F>a de los
.B \-U, --dhcp-vendorclass=set:<tag>,<vendor-class>
Trazar desde un string vendor-class a una etiqueta. La mayor<6F>a de los
clientes DHCP proveen una "vendor class" la cual representa, en cierto
sentido, el tipo de host. Esta opci<63>n traza clases de vendedor a network
ids, de tal forma que opciones DHCP pueden ser selectivamente entregadas
a diferentes clases de hosts. Por ejemplo
.B dhcp-vendorclass=printers,Hewlett-Packard JetDirect
.B dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect
peritir<EFBFBD>a que opciones sean fijadas solo para impresoras HP as<61>:
.B --dhcp-option=printers,3,192.168.4.4
.B --dhcp-option=tag:printers,3,192.168.4.4
El string vendor-class es coordinado con el vendor-class proveido por
el cliente, para permitir coincidencias borrosas.
el cliente, para permitir coincidencias borrosas. El prefijo set: es
opcional, pero permitido por razones de consistencia.
.TP
.B \-j, --dhcp-userclass=<network-id>,<user-class>
Trazar desde un string user-class a un network id (con coordinaci<63>n
.B \-j, --dhcp-userclass=set:<tag>,<user-class>
Trazar desde un string user-class a una etiqueta (con coordinaci<63>n
substring, como con vendor-class). La mayor<6F>a de los clientes DHCP
proveen un "user class" el cual es configurable. Esta opci<63>n traza
clases user a network ids, de tal manera que opciones DHCP puedan
@@ -708,26 +762,43 @@ ser selectivamente enviadas a diferentes tipos de hosts. Es posible,
por ejemplo, usar esto para especificar una impresora diferente para
hosts en la clase "cuentas" que para los de la clase "ingenieria".
.TP
.B \-4, --dhcp-mac=<network-id>,<direcci<63>n MAC>
Trazar desde una direcci<63>n MAC a una network id. La direcci<63>n MAC
.B \-4, --dhcp-mac=set:<tag>,<MAC address>
Trazar desde una direcci<63>n MAC a una etiqueta. La direcci<63>n MAC
puede incluir comod<6F>nes. Por ejemplo:
.B --dhcp-mac=3com,01:34:23:*:*:*
.B --dhcp-mac=set:3com,01:34:23:*:*:*
fijar<EFBFBD>a el tag "3com" a cualquier host el cual su MAC coincida con
el patr<74>n.
.TP
.B --dhcp-circuitid=<network-id>,<circuit-id>, --dhcp-remoteid=<network-id>,<remote-id>
Trazar de opciones agente de relay RFC3046 a opciones network-id. Estos
Trazar de opciones agente de relay RFC3046 a etiquetas. Estos
datos pueden ser prove<76>dos por agentes de relay DHCP. El circuit-id o
remote-id es normlamente brindado como hex separado por doblepuntos, pero
tambi<EFBFBD>n se permite un string simple. Si se obtiene una coincidencia exacta
entre el circuit o agent ID y uno prove<76>do por un agente de relay,
network-id es fijado.
la etiqueta es fijada.
.TP
.B --dhcp-subscrid=<network-id>,<subscriber-id>
Trazar de opciones relay subscriber-id RFC3993 a opciones network-id.
.B --dhcp-subscrid=set:<tag>,<subscriber-id>
Trazar de opciones relay subscriber-id RFC3993 a etiquetas.
.TP
.B --dhcp-match=<network-id>,<option number>|option:<option name>|vi-encap:<enterprise>[,<valor>]
Sin un valor, fijar la etiqueta network-id si el cliente env<6E>a una opci<63>n
.B --dhcp-proxy[=<ip addr>]......
Un agente de relay normal es usado solamente para reenviar las partes
iniciales de una interacci<63>n DHCP con el servidor DHCP. Una vez que
un cliente es configurado, se comunica diectamente con el servidor. Esto
es indeseable si el agente de relay est<73> agregando informaci<63>n extra a
los paquetes DHCP, tal como usado por
.B dhcp-circuitid
y
.B dhcp-remoteid.
Una implementaci<63>n relay completa puede usar la opci<63>n serverid-override
RFC 5107 para obligar al servidor DHCP a usar el relay como un proxy
completo, con todos los paquetes pasando a travez de el. Esta opci<63>n
provee una manera alternativa de hacer la misma cosa, para relays que
no tienen soporte RFC 5107. Brindada por si sola, manipula el server-id
para todas las interacciones via relays. Si una lista de IPs es brindada,
solo interacciones via relays en esas direcciones son afectadas.
.TP
.B --dhcp-match=set:<tag>,<option number>|option:<option name>|vi-encap:<enterprise>[,<value>]
Sin un valor, fijar la etiqueta si el cliente env<6E>a una opci<63>n
DHCP del n<>mero o valor brindado. Cuando un valor es brindado, fijar la
etiqueta solo si la opci<63>n es enviada y coincide con el valor. El valor puede
ser de la forma "01:ff:*:02", caso en el cual el valor debe coincidir (aparte
@@ -737,7 +808,7 @@ del final del valor. El valor tambi
caso en el cual la opci<63>n enviada es tratada como un array, y un elemento debe
coincidir, as<61> que
--dhcp-match=efi-ia32,option:client-arch,6
--dhcp-match=set:efi-ia32,option:client-arch,6
fijar<EFBFBD> la etiqueta a "efi-ia32" si el n<>mero 6 aparece en la lista de
architecturas enviada por los clientes en opci<63>n 93. (Ver RFC 4578 para
@@ -745,42 +816,58 @@ detalles.) Si el valor es un string, coincidencia substring es usada.
La forma especial con vi-encap:<enterpise number> busca coincidencia con
clases de vendedor identificadoras para el enterprise especificado. Por
favor ver RFC 3925 para mas detalles sobre las bestias raras e interesantes.
favor ver RFC 3925 para mas detalles sobre estas bestias raras e interesantes.
.TP
.B \-J, --dhcp-ignore=<network-id>[,<network-id>]
Cuando todos los network ids brindados coincidan con el juego de
network ids derivados de las clases net, host, y vendor, ignorar
el host y no brindarle un arriendo DHCP.
.B --tag-if=set:<tag>[,set:<tag>[,tag:<tag>[,tag:<tag>]]]
Llevar a cabo operaciones boolean en etiquetas. Cualquier etiqueta
que aparece como set:<tag> es fijada si todas las etiquetas que aparecen
como tag:<tag> estan fijadas, (o desfijadas cuando tag:!<tag> es
usado). Si ning<6E>n tag:<tag> aparece, etiquetas set:<tag> son fijadas
incondicionalmente. Cualquier cantidad de formas set: y tag:
pueden aparecer, en cualquier orden. L<>neas tag-if son ejecutadas
en orden, as<61> que si la etiqueta en tag:<tag> es una etiqueta fijada
por otra
.B tag-if,
la l<>nea que fija la etiqueta debe preceder a la que comprueba.
.TP
.B --dhcp-ignore-names[=<network-id>[,<network-id>]]
Cuando todos los network-ids brindados coinciden con el juego de
network-ids derivado de la red, host, classes de vendedor y usuario,
ignorar cualquier nombre de host proveido por el host. N<>tese que,
a diferencia de dhcp-ignore, es permisible no brindar ning<6E>n tag netid,
.B \-J, --dhcp-ignore=tag:<tag>[,tag:<tag>]
Cuando todoas las etiquetas brindadas aparecen en el juego de etiquetas
ignorar el host y no brindarle un arriendo DHCP.
.TP
.B --dhcp-ignore-names[=tag:<tag>[,tag:<tag>]]
Cuando todos las etiquetas brindadas aparecen en el juego de etiquetas, ignorar cualquier nombre de host proveido por el host. N<>tese que,
a diferencia de dhcp-ignore, es permisible no brindar ninguna etiqueta,
y en tal caso nombres de host proveidos por clientes DHCP siempre son
ignorados, y hosts DHCP son agregados al DNS usando solo la configuraci<63>n
dhcp-host en dnsmasq y el contenido de /etc/hosts y /etc/ethers.
.TP
.B --dhcp-broadcast=<network-id>[,<network-id>]
Cuando todos los network-ids brindados coinciden con el juego de network-ids
derivados de la red, host, clases de vendedor y usuarios, siempre usar
broadcast para comunicarse con el host cuando est<73> sin configurar. La
mayor<EFBFBD>a de clientes DHCP que necesitan respuestas broadcast fijan una
opci<EFBFBD>n en sus pedidos para que esto pase automaticamente, algunos
clientes BOOTP viejos no lo hacen.
.B --dhcp-generate-names=tag:<tag>[,tag:<tag>]
Generar un nombre para clientes DHCP que de otra forma no tienen uno,
usando la direcci<63>n MAC expresada en hex, separada por guiones. N<>tese
que si un host provee un nombre, ser<65> usado preferiblemente sobre este,
a menos que
.B --dhcp-ignore-names
est<EFBFBD> fijado.
.TP
.B \-M, --dhcp-boot=[net:<network-id>,]<filename>,[<servername>[,<server address>]]
.B --dhcp-broadcast[=tag:<tag>[,tag:<tag>]]
Cuando todas las etiquetas aparecen en el juego de etiquetas, siempre
usar broadcast para comunicar con el host cuando no est<73> configurado.
Es permisible omitir las etiquetas, caso en el cual esto es
incondicional. La mayor<6F>a de clientes DHCP que necesitan
respuestas broadcast fijan una opci<63>n en sus pedidos para que esto pase automaticamente, algunos clientes BOOTP viejos no lo hacen.
.TP
.B \-M, --dhcp-boot=[tag:<tag>,]<filename>,[<servername>[,<server address>]]
Fijar opciones BOOTP que han de ser devueltas por el servidor DHCP. Nombre
y direcci<63>n de servidor son opcionales: si no son brindadas, el nombre es
dejado en blanco, y la direcci<63>n es fijada a la de la m<>quina que corre
dnsmasq. Si dnsmasq est<73> brindando servicio TFTP (ver
.B --enable-tftp
) entonces solo el nombre de archivo es requirido aqu<71> para habilitar
el inicio atrav<61>z de una red. Si las opcionales network-ids son brindadas,
el inicio atrav<61>z de una red. Si las opcionales etiquetas son brindadas,
ellas deber<65>n coincidir para que esta configuraci<63>n sea enviada. N<>tese
que network-ids est<73>n prefijadas con "net:" para distinguirlas.
.TP
.B --pxe-service=[net:<network-id>,]<CSA>,<texto de men<EFBFBD>>[,<nombre base>|<tipo de servicio boot>][,<direcci<63>n de servidor>]
.B --pxe-service=[tag:<tag>,]<CSA>,<menu text>[,<basename>|<bootservicetype>][,<server address>]
La mayor<6F>a de usos para boot-ROMS PXE simplemente permiten al sistema PXE
obtener una direcci<63>n IP y entonces bajar el archivo especificado por
.B dhcp-boot
@@ -808,7 +895,7 @@ de servicio boot o nombre de archivo es brindado (o un tipo de servicio boot
de 0 es especificado), entonces la opci<63>n de men<65> abortar<61> el proceso net boot
y continuar<61> desde el medio local.
.TP
.B --pxe-prompt=[net:<network-id>,]<prompt>[,<timeout>]
.B --pxe-prompt=[tag:<tag>,]<prompt>[,<timeout>]
Fijar esto hace que un aviso sea expuesto despues del boot PXE. Si el timeout
es brindado, entonces despues que el timeout se haya vencido sin input del
teclado, la primera opci<63>n del men<65> sera automaticamente ejecutada. Si el
@@ -834,7 +921,7 @@ en
.TP
.B \-X, --dhcp-lease-max=<n<>mero>
Limita a dnsmasq a el n<>mero especificado de arriendos DHCP. El
predeterminado es 150. El limite es para prevenir ataques DoS desde
predeterminado es 1000. El limite es para prevenir ataques DoS desde
hosts que crean cientos de arriendos y usan mucha de la memoria del
proceso dnsmasq.
.TP
@@ -874,7 +961,7 @@ cuidado.
.TP
.B --log-dhcp
Bitacor<EFBFBD>o extra para DHCP: Bitacorear todas las opciones enviadas a
clientes DHCP y las etiquetas netid usadas para determinarlos.
clientes DHCP y las etiquetas usadas para determinarlos.
.TP
.B \-l, --dhcp-leasefile=<path>
Usar el archivo especificado para almacenar informaci<63>n de arriendos
@@ -883,6 +970,7 @@ DHCP.
.B \-6 --dhcp-script=<path>
Cuando un arriendo DHCP nuevo es creado, o uno viejo es
destruido, el ejecutable especificado por esta opci<63>n es ejecutado.
<path> debe ser un pathname absoluto, ninguna b<>squeda PATH ocurre.
Los argumentos para el binario son "add", "old", o "del", la direcci<63>n
MAC del host, la direcci<63>n IP, y el hostname, si es
conocido. "add" significa que un arriendo ha sido creado, "del" que
@@ -894,40 +982,64 @@ que no es ethernet, tendr
"06-01:23:45:67:89:ab" para token ring. El proceso es ejecutado como root
(asumiendo que dnsmasq fue originalmente ejecutado como root) a<>n si dnsmasq
est<EFBFBD> configurado para cambiar su UID a un usuario sin privilegios.
El ambiente es heredado del usuario que ha invocado a dnsmasq, y si el
host brind<6E> un client-id, es almacenado en la variable de ambiente
DNSMASQ_CLIENT_ID. Si el dominio completamente calificado del host
es conocido, la parte de dominio es almacenada en DNSMASQ_DOMAIN. Si
el cliente brinda informaci<63>n de clase de vendedor, nombre de host,
o clase de usuario, estos son brindados en las variables
El ambiente es heredado del usuario que ha invocado a dnsmasq, con algunas
o todas de las siguientes variables agregadas.
DNSMASQ_CLIENT_ID si el host brindo un client-id.
DNSMASQ_DOMAIN si el nombre de dominio completamente calificado del host
es conocido, esto es fijado a la parte del dominio.
Si el cliente brinda vendor-class, hostname o user-class, estos son
brindados en las variables
DNSMASQ_VENDOR_CLASS, DNSMASQ_SUPPLIED_HOSTNAME, y
DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn, pero solo para acciones "add"
y "old" cuando un host reanuda un arriendo existente, dado a que estos
datos no son almacenados en la base de datos de arriendos de dnsmasq.
Si dnsmasq fue compilado con HAVE_BROKEN_RTC, entonces la duraci<63>n del
arriendo (en segundos) es almacenada en DNSMASQ_LEASE_LENGTH, de otra
manera el tiempo de vencimiento es almacenado en DNSMASQ_LEASE_EXPIRES.
El n<>mero de segundos faltante para el vencimiento del arriendo siempre
es almacenado en DNSMASQ_TIME_REMAINING.
Si un arriendo sol<6F>a tener un nombre de host, el cual es removido, un
evento "old" es generado con el nuevo estado del arriendo, (por ejemplo, sin
nombre), y el nombre anterior es brindado en la variable de ambiente
DNSMASQ_OLD_HOSTNAME. DNSMASQ_INTERFACE almacena el nombre de la interface
DNSMASQ_OLD_HOSTNAME.
DNSMASQ_INTERFACE almacena el nombre de la interface
en la cual lleg<65> el pedido; esto no es fijado para acciones "viejas"
cuando dnsmasq re-inicia. DNSMASQ_RELAY_ADDRESS es fijado si el cliente
cuando dnsmasq re-inicia.
DNSMASQ_RELAY_ADDRESS es fijado si el cliente
us<EFBFBD> un relay DHCP para contactar a dnsmasq y la direcci<63>n IP del relay
es conocida. DNSMASQ_TAGS contiene todas las etiquetas network-id fijadas
es conocida.
DNSMASQ_TAGS contiene todas las etiquetas network-id fijadas
durante la transacci<63>n DHCP, separadas por espacios.
Todos los descriptores de archivo est<73>n cerrados
excepto stdin, stdout, y stderr los cuales est<73>n abiertos a /dev/null
(excepto en modo debug).
Este gui<75>n no es invocado concurrentemente: si cambios de arriendos
subsiguientes ocurren, el gui<75>n no es invocado otra vez hasta que
cualquier invocaci<63>n existente haga exit. Al inicio de dnsmasq, el gui<75>n
Este gui<75>n no es invocado concurrentemente: m<>ximo una instamcia del
gui<EFBFBD>n est<73> corriendo a la vez (dnsmasq espera a que una instancia de
gui<EFBFBD>n haga exit antes de correr la siguiente). Cambios a la base de
datos de arriendos que requieren que el gui<75>n sea invocado son puestos
en cola esperando el exit de una instancia corriente. Si esta cola permite
que cambios multiples de estado le ocurran a un arriendo individual antes
de que el gui<75>n pueda ser ejecutado entonces estados anteriores son descartados
y el estado actual del arriendo es reflejado cuando el gui<75>n finalmente corre.
Al inicio de dnsmasq, el gui<75>n
ser<EFBFBD> invocado para todos los arriendos existentes mientras van siendo
le<EFBFBD>dos desde el archivo de arriendos. Arriendos vencidos ser<65>n llamados
con "del" y otros con "old". <path> debe ser un path absoluto, ninguna
b<EFBFBD>squeda PATH ocurre. Cuando dnsmasq recibe una se<73>al HUP, el gui<75>n ser<65>
b<EFBFBD>squeda PATH ocurre cuando arriendos dnsmasq ser<65>n llamados con "del"
y otros con "old". Cuando dnsmasq recibe una se<73>al HUP, el gui<75>n ser<65>
invocado para arriendos existentes con un evento "old".
.TP
.B --dhcp-scriptuser
@@ -1000,18 +1112,20 @@ sin una direcci
.B --dhcp-fqdn
est<EFBFBD> fijado.
.TP
.B --enable-tftp
.B --enable-tftp[=<interface>]
Habilitar la funci<63>n de servidor TFTP. Esto est<73> deliberadamente limitado
a lo necesario para hacerle a un cliente un inicio v<>a red. Solo lectura es
permitida; las extensiones tsize y blksize son soportadas (tsize solo es
soportada en modo octeto).
soportada en modo octeto). Ver secci<63>n de NOTAS para el uso de el argumento
de interface.
.TP
.B --tftp-root=<directorio>
.B --tftp-root=<directory>[,<interface>]
Buscar, relativo al directorio brindado, archivos para transferir mediante el
uso de TFTP. Cuando esta opci<63>n est<73> fijada, paths TFTP que incluyen ".." son
rechazados, para prevenir que clientes salgan de la ra<72>z especificada. Paths
absolutos (los que comienzan con "/") est<73>n permitidos, pero deben estar
dentro del tftp-root.
dentro del tftp-root. Si el argumento opcional de interface es brindado, el
directorio es solo usado para pedidos TFTP v<>a esa interface.
.TP
.B --tftp-unique-root
Agregar la direcci<63>n IP del cliente TFTP como un componente path del lado del
@@ -1199,36 +1313,46 @@ apunta a un nombre sombreado, entonces buscando el CNAME a trav
dnsmasq resultar<61> en que la direcci<63>n no-sombreada ser<65> asociada con
el destino del CNAME. Para circumventar esto, agregar el CNAME a
/etc/hosts de tal manera que el CNAME es sombreado tambi<62>n.
.PP
El sistema network-id funciona de la siguiente manera: Para cada pedido
DHCP, dnsmasq colecciona un juego de etiquetas network-id v<>lidas,
una del
El sistema de etiquetas funciona de la siguiente manera: Para cada pedido
DHCP, dnsmasq colecciona un juego de etiquetas v<EFBFBD>lidas de l<>neas de
configuraci<EFBFBD>n activas que incluyen set:<tag>, incluyendo una del
.B dhcp-range
usado para alocar la direcci<63>n, una de cualquier
.B dhcp-host
que coincida (y "known" si un dhcp-host coincide), la etiqueta "bootp"
para pedidos BOOTP, una etiqueta cuyo nombre es el nombre de la
interface donde lleg<65> el pedido, y posiblemente muchas de clases
de vendedor y usuario que coincidan que hayan sido enviadas por
el cliente DHCP. Cualquier opci<63>n
que coincida (y "known" si un dhcp-host coincide).
La etiqueta "bootp" es fijada para pedidos BOOTP, y una etiqueta cuyo
nombre es el nombre de la interface donde lleg<65> el pedido tambien es
fijada.
Cualquier linea de configuraci<63>n que incluya uno o mas
construcciones tag:<tag> solo ser<65> v<>lida si todas las etiquetas
coinciden en el juego derivado arriba. T<>picamente esto es dhcp-option.
.B dhcp-option
que tenga etiquetas network-id ser<EFBFBD> usada en preferencia de una opci<EFBFBD>n
que tenga etiquetas ser<EFBFBD> usada en preferencia de una opci<EFBFBD>n
.B dhcp-option,
sin etiqueta, con tal que _todas_ las etiquetas coincidan en alguna
parte del juego coleccionado describido arriba. El prefijo "#" en una
etiqueta significa "no" as<61> que --dhcp=option=#purple,3,1.2.3.4 env<6E>a
la opci<63>n cuando la etiqueta network-id "purple" no est<73> en el juego
de etiquetas v<>lidas.
parte del juego coleccionado describido arriba. El prefijo '!' en una
etiqueta significa "no" as<61> que --dhcp=option=tag:!purple,3,1.2.3.4 env<6E>a
la opci<63>n cuando la etiqueta "purple" no est<73> en el juego
de etiquetas v<>lidas. (Si se est<73> usando esto en una l<>nea de comandos
en vez de un archivo de configuraci<63>n, asegurese de escapar !, el cual
es un metacaracter de shell.)
.PP
N<EFBFBD>tese que para
.B dhcp-range
ambos tag:<tag> y set:<tag> son permitidos, para seleccionar el rango
en uso basado en (por ejemplo) dhcp-host, y para afectar las opciones
enviadas, basadas en el rango seleccionado.
Este sistema evolucion<6F> de uno anterior mas limitado y para compatibildad
reversa "net:" puede ser usada en vez de "tag:" y "set:" puede ser
omitida. (Excepto en
.B dhcp-host,
donde "net:" puede ser usado en vez de "set:".) Por la misma raz<61>n, '#'
puede ser usado en vez de '!' para indicar NO.
.PP
Si el network-id en un
.B dhcp-range
es prefijado con "net:", entonces su significado cambia de "fijar
etiqueta" a "coincidir con etiqueta". O sea que si hay m<>s de un
dhcp-range en en una subred, y uno tiene una etiqueta network-id la
cual est<73> fijada (por ejemplo una opci<63>n de clase de vendedor) entonces
hosts que fijen la etiqueta network-id ser<65>n alocados direcciones en
el rango etiquetado.
.PP
El servidor DHCP de dnsmasq funcionar<61> como servidor BOOTP tambien,
con tal que las direcciones MAC y IP de los clientes sean brindadas,
ya sea usando configuraciones
@@ -1239,11 +1363,54 @@ o en
.B dhcp-range
est<EFBFBD> presente para activar el servidor DHCP en una red particular.
(Fijar --bootp-dynamic elimina la necesidad de trazados est<73>ticos.) El
par<EFBFBD>metro de nombre de archivos en un pedido BOOTP es revisado para
ver si coincide con alg<6C>n network-id en configuraci<63>nes
.B dhcp-option
al igual que la etiqueta "bootp", permitiendo as<EFBFBD> alg<EFBFBD>n control sobre
las opciones devueltas a diferentes clases de hosts.
par<EFBFBD>metro de nombre de archivos en un pedido BOOTP es usado como
una etiqueta, al igual que la etiqueta "bootp", permitiendo as<61> alg<6C>n
control sobre las opciones devueltas a diferentes clases de hosts.
.B dhcp-range
puede tener un nombre de interface brindado como
"interface:<interface-name>". La sem<65>ntica de esto es as<61>:
Para DHCP, si cualquier otro dhcp-range existe _sin_ un nombre de
interface, entonces el nombre de interface es ignorado y dnsmasq
se comporta como si las partes de interface no existieran, de otra forma
DHCP solo se provee a interfaces mencionadas en declaraciones
dhcp-range. Para DNS, si no hay opciones
.B --interface
o
.B --listen-address
el comportamiento no se modifica por la parte de interface. Si cualquiera
de estas opciones est<73> presente, las interfaces mencionadas en dhcp-ranges
son agregadas all juego que obtienen servicio DNS.
Similarmente,
.B enable-tftp
puede tomar un nombre de interface, el cual habilita TFTP solo para una
interface en particular, ignorando opciones
.B --interface
o
.B --listen-address.
Adicionalmente,
.B --tftp-secure
y
.B --tftp-unique-root
y
.B --tftp-no-blocksize
son ignorados por pedidos desde dichas interfaces. (Una directiva
.B --tftp-root
brindando un path ra<72>z y una interface debe ser brindada tambien.)
Estas reglas pueden parecer raras a primera vista, pero permiten que
una simple linea de la forma
"dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" sea agregada a
configuraci<EFBFBD>n dnsmasq, lo cual brinda servicios DHCP y DNS a esa interface,
sin afectar los servicios en otras interfaces y irrespectivamente de
la existencia o no de lineas "interface=<interface>" en alguna otra parte
de la configuraci<63>n dnsmasq.
"enable-tftp=virt0" y "tftp-root=<root>,virt0" hacen el mismo trabajo
para TFTP.
La idea es que una linea as<61> pueda ser agregada automaticamente
por libvirt o sistemas equivalentes, sin estorbar alguna
configuraci<EFBFBD>n manual.
.SH C<EFBFBD>DIGOS EXIT
.PP
@@ -1276,10 +1443,8 @@ no escalaban tan bien.
.PP
Dnsmasq es capaz de soportar con DNS y DHCP a por lo menos mil (1,000)
clientes. Por supuesto que para lograr esto debe aumentarse el valor de
.B --dhcp-lease-max
, y tiempos de arriendo no deben ser muy cortos (menos de una hora).
El valor de
clientes. Los tiempos de arriendo no deben ser muy cortos (menos
de una hora). El valor de
.B --dns-forward-max
puede ser aumentado: comienze con el equivalente a el n<>mero de clientes y
aum<EFBFBD>ntelo si parece lento el DNS. N<>tese que el rendimiento DNS depende

426
man/fr/dnsmasq.8
View File

@@ -73,6 +73,12 @@ option permet de doner une valeur de durée de vie par défaut (en secondes) que
dnsmasq utilise pour mettre les réponses négatives dans son cache, même en
l'absence d'enregistrement SOA.
.TP
.B --max-ttl=<durée>
Définie la valeur de TTL maximum qui sera fournie aux clients. La valeur maximum
de TTL spécifiée sera fournie aux clients en remplacement de la vraie valeur de TTL
si cette dernière est supérieure. La valeur réelle de TTL est cependant conservée dans
le cache afin d'éviter de saturer les serveurs DNS en amont.
.TP
.B \-k, --keep-in-foreground
Ne pas aller en tâche de fond au lancement, mais en dehors de cela, fonctionner
normalement. Ce mode est prévu pour les cas où Dnsmasq est lancé par daemontools
@@ -94,10 +100,12 @@ réception d'un signal SIGUSR1.
Définit la "facility" dans laquelle Dnsmasq enverra ses entrées syslog, par
défaut DAEMON ou LOCAL0 si le mode debug est activé. Si la "facility" contient
au moins un caractère "/", alors Dnsmasq considère qu'il s'agit d'un fichier et
enverra les logs dans le fichier correspondant à la place du syslog. (Les
erreurs lors de la lecture de la configuration vont toujours vers le syslog,
mais tous les messages postérieures à un démarrage réussi seront exclusivement
envoyés vers le fichier de logs). Lorsque Dnsmasq est configuré pour envoyer
enverra les logs dans le fichier correspondant à la place du syslog. Si la
"facility" est '-', alors dnsmasq envoie les logs sur la sortie d'erreur
standard stderr. (Les erreurs lors de la lecture de la configuration vont
toujours vers le syslog, mais tous les messages postérieurs à un démarrage
réussi seront exclusivement envoyés vers le fichier de logs).
Lorsque Dnsmasq est configuré pour envoyer
ses traces vers un fichier, la réception d'un signal SIGUSR2 entraine la
fermeture et réouverture du fichier. Cela permet la rotation de fichiers de
traces sans nécessiter l'arrêt de Dnsmasq.
@@ -317,6 +325,19 @@ serveurs amonts suite à une résolution de nom. Cela bloque les attaques cherch
à détourner de leur usage les logiciels de navigation web ('browser') en s'en
servant pour découvrir les machines situées sur le réseau local.
.TP
.B --rebind-localhost-ok
Exclue 127.0.0/8 des vérifications de réassociation DNS. Cette gamme d'adresses
est retournée par les serveurs Realtime Blackhole (RBL, utilisés dans la
lutte contre le spam), la bloquer peut entraîner des disfonctionnements de ces
services.
.TP
.B --rebind-domain-ok=[<domaine>]|[[/<domaine>/[<domaine>/]
Ne pas détecter ni bloquer les actions de type dns-rebind pour ces domaines.
Cette option peut prendre comme valeur soit un nom de domaine soit plusieurs
noms de domains entourés par des '/', selon une syntaxe similaire à l'option
--server, c-à-d :
.B --rebind-domain-ok=/domaine1/domaine2/domaine3/
.TP
.B \-n, --no-poll
Ne pas vérifier régulièrement si le fichier /etc/resolv.conf a été modifié.
.TP
@@ -354,6 +375,20 @@ option
.B -S
est autorisée, en répétant les domaines et adresses IP comme requis.
Le domaine le plus spécifique l'emporte sur le domaine le moins spécifique,
ainsi :
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/2.3.4.5
enverra les requêtes pour *.google.com à 1.2.3.4, à l'exception des requêtes
*www.google.com, qui seront envoyées à 2.3.4.5.
L'adresse spéciale '#' signifie "utiliser les serveurs standards", ainsi
.B --server=/google.com/1.2.3.4
.B --server=/www.google.com/#
enverra les requêtes pour *.google.com à 1.2.3.4, à l'exception des requêtes
pour *www.google.com qui seront envoyées comme d'habitude (c-à-d aux serveurs
définis par défaut).
Il est également permis de donner une option
.B -S
avec un nom de domaine mais sans
@@ -502,7 +537,7 @@ lorsqu'un serveur web a la résolution de nom activée pour l'enregistrement de
son journal des requêtes, ce qui peut générer un nombre important de requêtes
simultanées.
.TP
.B \-F, --dhcp-range=[[net:]identifiant de réseau,]<adresse de début>,<adresse de fin>[,<masque de réseau>[,<broadcast>]][,<durée de bail>]
.B \-F, --dhcp-range=[interface:<interface>,][tag:<label>[,tag:<label>],][set:<label],]<adresse de début>,<adresse de fin>[,<masque de réseau>[,<broadcast>]][,<durée de bail>]
Active le serveur DHCP. Les adresses seront données dans la plage comprise entre
<adresse de début> et <adresse de fin> et à partir des adresses définies
statiquement dans l'option
@@ -522,10 +557,11 @@ relais DHCP ("relay agent"). L'adresse de broadcast est toujours optionnelle.
Il est toujours possible d'avoir plus d'une plage DHCP pour un même
sous-réseau.
L'identifiant de réseau optionnel est un label alphanumérique qui permet de
marquer ce réseau afin de fournir des options DHCP spécifiques à chaque réseau.
Lorsque préfixé par 'net:', la signification change est au lieu de définir un
L'identifiant de label optionnel
.B set:<label>
fournie une étiquette alphanumérique qui identifie ce réseau, afin de permettre
la fourniture d'options DHCP spécifiques à chaque réseau.
Lorsque préfixé par 'tag:', la signification change, et au lieu de définir un
label, il définit le label pour laquelle la règle s'applique. Un seul label peut-
être défini mais plusieurs labels peuvent coïncider.
@@ -545,8 +581,11 @@ spécifié. (voir
et
.B pxe-service
pour plus de détails).
La section interface:<nom d'interface> n'est normalement pas utilisée. Se
référer aux indications de la section NOTES pour plus de détail à ce sujet.
.TP
.B \-G, --dhcp-host=[<adresse matérielle>][,id:<identifiant client>|*][,net:<identifiant de réseau>][,<adresse IP>][,<nom d'hôte>][,<durée de bail>][,ignore]
.B \-G, --dhcp-host=[<adresse matérielle>][,id:<identifiant client>|*][,set:<label>][,<adresse IP>][,<nom d'hôte>][,<durée de bail>][,ignore]
Spécifie les paramètres DHCP relatifs à un hôte. Cela permet à une machine
possédant une adresse matérielle spécifique de se voir toujours allouée les
mêmes nom d'hôte, adresse IP et durée de bail. Un nom d'hôte spécifié comme
@@ -560,9 +599,15 @@ spécifie à Dnsmasq de fournir à la machine d'adresse matérielle
.B --dhcp-host=lap,192.168.0.199
spécifie à Dnsmasq d'allouer toujours à la machine portant le nom lap
l'adresse IP 92.168.0.199. Les adresses allouées comme ceci ne sont pas
contraintes dans une plage d'adresse spécifiée par une option --dhcp-range, mais
elles doivent être sur un réseau servi par le serveur DHCP. Il est possible
l'adresse IP 192.168.0.199.
Les adresses allouées de la sorte ne sont pas contraintes à une plage d'adresse
spécifiée par une option --dhcp-range, mais elles se trouver dans le même
sous-réseau qu'une plage dhcp-range valide. Pour les sous-réseaux qui n'ont pas
besoin d'adresses dynamiquement allouées, utiliser le mot-clef "static" dans la
déclaration de plage d'adresses dhcp-range.
Il est possible
d'utiliser des identifiants clients plutôt que des adresses matérielles pour
identifier les hôtes, en préfixant par ceux-ci par 'id:'. Ainsi,
.B --dhcp-host=id:01:02:03:04,.....
@@ -578,7 +623,13 @@ identifiant client mais pas les autres.
Si un nom apparaît dans /etc/hosts, l'adresse associée peut être allouée à un
bail DHCP mais seulement si une option
.B --dhcp-host
spécifiant le nom existe par ailleurs. Le mot clef "ignore" ("ignorer") indique
spécifiant le nom existe par ailleurs. Seul un nom d'hôte peut-être donné dans
une option
.B dhcp-host
, mais les alias sont possibles au travers de l'utilisation des CNAMEs. (Voir
.B --cname
).
Le mot clef "ignore" ("ignorer") indique
à Dnsmasq de ne jamais fournir de bail DHCP à une machine. La machine peut être
spécifiée par son adresse matérielle, son identifiant client ou son nom d'hôte.
Par exemple
@@ -586,14 +637,15 @@ Par exemple
Cela est utile lorsqu'un autre serveur DHCP sur le réseau doit être utilisé par
certaines machines.
Le paramètre net:<identifiant réseau> permet de définir un
Le paramètre set:<identifiant réseau> permet de définir un
identifiant de réseau lorsque l'option dhcp-host est utilisée. Cela peut servir
à sélectionner des options DHCP juste pour cet hôte. Lorsqu'une machine coïncide
avec une directive dhcp-host (ou une impliquée par /etc/ethers), alors
l'identifiant réseau réservé "known" ("connu") est associé. Cela permet à
à sélectionner des options DHCP juste pour cet hôte. Plus d'un label peut être
fourni dans une directive dhcp-host (et dans cette seule directive). Lorsqu'une
machine coïncide avec une directive dhcp-host (ou une impliquée par
/etc/ethers), alors le label réservé "known" ("connu") est associé. Cela permet à
Dnsmasq d'être configuré pour ignorer les requêtes issus de machines inconnue
par le biais de
.B --dhcp-ignore=#known.
.B --dhcp-ignore=tag:!known.
Les adresses ethernet (mais pas les identifiants clients) peuvent être définies
avec des octets joker, ainsi par exemple
@@ -649,7 +701,7 @@ par Dnsmasq, ces lignes ont exactement le même effet que l'option
contenant les mêmes informations. /etc/ethers est relu à la réception d'un
signal SIGHUP par Dnsmasq.
.TP
.B \-O, --dhcp-option=[<identifiant_de_réseau>,[<identifiant_de_réseau>,]][encap:<option>,][vi-encap:<entreprise>,][vendor:[<classe_vendeur>],][<option>|option:<nom d'option>],[<valeur>[,<valeur>]]
.B \-O, --dhcp-option=[tag:<label>,[tag:<label>]][encap:<option>,][vi-encap:<entreprise>,][vendor:[<classe_vendeur>],][<option>|option:<nom d'option>],[<valeur>[,<valeur>]]
Spécifie des options différentes ou supplémentaires pour des clients DHCP. Par
défaut, Dnsmasq envoie un ensemble standard d'options aux clients DHCP : le
masque de réseau et l'adresse de broadcast sont les mêmes que pour l'hôte
@@ -675,8 +727,8 @@ L'adresse 0.0.0.0 prends ici le sens "d'adresse de la machine sur laquelle
tourne Dnsmasq". Les types de données autorisées sont des adresses IP sous la
forme de 4 chiffres séparés par des points, un nombre décimal, une liste de
caractères hexadécimaux séparés par des 2 points, ou une chaîne de caractères.
Si des identifiants de réseaux sont fournis, alors cette option n'est envoyée
qu'aux réseaux dont tous les identifiants coïncident.
Si des labels optionnels sont fournis, alors cette option n'est envoyée
qu'aux réseaux dont tous les labels coïncident avec ceux de la requête.
Un traitement spécial est effectué sur les chaînes de caractères fournies pour
l'option 119, conformément à la RFC 3397. Les chaînes de caractères ou les
@@ -738,7 +790,7 @@ Le numéro dans la section vi-encap: est le numéro IANA de l'entreprise servant
L'adresse 0.0.0.0 n'est pas traitée de manière particulière lorsque fournie dans
une option encapsulée.
.TP
.B --dhcp-option-force=[<identifiant de réseau>,[<identifiant de réseau>,]][encap:<option>,][vi-encap:<entreprise>,][vendor:[<classe de vendeur>],]<option>,[<valeur>[,<valeur>]]
.B --dhcp-option-force=[tag:<label>,[tag:<label>]][encap:<option>,][vi-encap:<entreprise>,][vendor:[<classe_vendeur>],][<option>|option:<nom d'option>],[<valeur>[,<valeur>]]
Cela fonctionne exactement de la même façon que
.B --dhcp-option
sauf que cette option sera toujours envoyée, même si le client ne la demande pas
@@ -756,22 +808,25 @@ quelques rares cas, perturber des clients vieux ou défectueux. Cette
option force le comportement à l'utilisation des valeurs "simples et sûres"
afin d'éviter des problèmes dans de tels cas.
.TP
.B \-U, --dhcp-vendorclass=<identifiant de réseau>,<classe de vendeur>
Associe une chaîne de classe de vendeur à un indentifiant de réseau. La plupart
.B \-U, --dhcp-vendorclass=set:<label>,<classe de vendeur>
Associe une chaîne de classe de vendeur à un label. La plupart
des clients DHCP fournissent une "classe de vendeur" ("vendor class") qui
représente, d'une certaine façon, le type d'hôte. Cette option associe des
classes de vendeur à des labels, de telle sorte que des options DHCP peuvent-être
fournie de manière sélective aux différentes classes d'hôtes. Par exemple,
.B dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect
ou
.B dhcp-vendorclass=printers,Hewlett-Packard JetDirect
permet de n'allouer des options qu'aux imprimantes HP de la manière suivante :
.B --dhcp-option=printers,3,192.168.4.4
.B --dhcp-option=tag:printers,3,192.168.4.4
La chaîne de caractères de la classe de vendeur founie en argument est cherchée
en temps que sous-chaîne de caractères au sein de la classe de vendeur fournie
par le client, de façon à permettre la recherche d'un sous-ensemble de la chaîne
de caractères ("fuzzy matching").
de caractères ("fuzzy matching"). Le préfixe set: est optionnel mais autorisé
afin de conserver une certaine homogénéité.
.TP
.B \-j, --dhcp-userclass=<identifiant de réseau>,<classe utilisateur>
Associe une chaîne de classe d'utilisateur à un identifiant réseau (effectue la
.B \-j, --dhcp-userclass=set:<label>,<classe utilisateur>
Associe une chaîne de classe d'utilisateur à un label (effectue la
recherche sur des sous-chaînes, comme pour les classes de vendeur). La plupart
des clients permettent de configurer une "classe d'utilisateur". Cette option
associe une classe d'utilisateur à un label, de telle manière qu'il soit
@@ -780,28 +835,44 @@ Il est possible, par exemple, d'utiliser ceci pour définir un serveur
d'impression différent pour les hôtes de la classe "comptes" et ceux de la
classe "ingénierie".
.TP
.B \-4, --dhcp-mac=<identifiant de réseau>,<adresse MAC>
Associe une adresse matérielle (MAC) à un identifiant réseau. L'adresse
.B \-4, --dhcp-mac=set:<label>,<adresse MAC>
Associe une adresse matérielle (MAC) à un label. L'adresse
matérielle peut inclure des jokers. Par exemple
.B --dhcp-mac=3com,01:34:23:*:*:*
.B --dhcp-mac=set:3com,01:34:23:*:*:*
permet de définir le label "3com" pour n'importe quel hôte dont l'adresse
matérielle coïncide avec les critères définis.
.TP
.B --dhcp-circuitid=<identifiant de réseau>,<identifiant de circuit>, --dhcp-remoteid=<identifiant de réseau>,<identifiant distant>
Associe des options de relais DHCP issus de la RFC3046 à des identifiants de
réseau. Cette information peut-être fournie par des relais DHCP. L'identifiant
.B --dhcp-circuitid=set:<label>,<identifiant de circuit>, --dhcp-remoteid=set:<label>,<identifiant distant>
Associe des options de relais DHCP issus de la RFC3046 à des labels.
Cette information peut-être fournie par des relais DHCP. L'identifiant
de circuit ou l'identifiant distant est normalement fourni sous la forme d'une
chaîne de valeurs hexadécimales séparées par des ":", mais il est également
possible qu'elle le soit sous la forme d'une simple chaîne de caractères. Si
l'identifiant de circuit ou d'agent correspond exactement à celui fourni par le
relais DHCP, alors l'identifiant de réseau est positionné.
relais DHCP, alors le label est apposé.
.TP
.B --dhcp-subscrid=<identifiant de réseau>,<identifiant d'abonné>
Associe des options de relais DHCP issues de la RFC3993 à des identifiants de
réseau.
.B --dhcp-subscrid=set:<label>,<identifiant d'abonné>
Associe des options de relais DHCP issues de la RFC3993 à des labels.
.TP
.B --dhcp-match=<identifiant de réseau>,<numéro d'option>|option:<nom d'option>|vi-encap:<entreprise>[,<valeur>]
Si aucune valeur n'est spécifiée, associe l'identifiant de réseau si le client
.B --dhcp-proxy[=<adresse ip>]......
Un agent relai DHCP normal est uniquement utilisé pour faire suivre les
éléments initiaux de l'interaction avec le serveur DHCP. Une fois que le
client est configuré, il communique directement avec le serveur. Cela n'est pas
souhaitable si le relais rajoute des informations supplémentaires aux paquets
DHCP, telles que celles utilisées dans
.B dhcp-circuitid
et
.B dhcp-remoteid.
Une implémentation complète de relai peut utiliser l'option serverid-override
de la RFC 5107 afin de forcer le serveur DHCP à utiliser le relai en temps que
proxy complet, de sorte que tous les paquets passent par le relai. Cette option
permet d'obtenir le même résultat pour des relais ne supportant pas la RFC
5107. Fournie seule, elle manipule la valeur de server-id pour toutes les
interactions via des relais. Si une liste d'adresses IP est donnée, seules les
interactions avec les relais dont l'adresse est dans la liste seront affectées.
.TP
.B --dhcp-match=set:<label>,<numéro d'option>|option:<nom d'option>|vi-encap:<entreprise>[,<valeur>]
Si aucune valeur n'est spécifiée, associe le label si le client
envoie une option DHCP avec le numéro ou le nom spécifié. Lorsqu'une valeur est
fournie, positionne le label seulement dans le cas où l'option est fournie et
correspond à la valeur. La valeur peut-être de la forme "01:ff:*:02", auquel
@@ -811,7 +882,7 @@ valeur peut aussi être de la même forme que dans
, auquel cas l'option est traitée comme un tableau de valeur, et un des
éléments doit correspondre, ainsi
--dhcp-match=efi-ia32,option:client-arch,6
--dhcp-match=set:efi-ia32,option:client-arch,6
spécifie le label "efi-ia32" si le numéro 6 apparaît dnas la liste
d'architectures envoyé par le client au sein de l'option 93. (se réferer
@@ -823,30 +894,50 @@ fait avec les classes de vendeur "identifiant de vendeur" ("vendor-identifying
vendor classes") pour l'entreprise dont le numéro est fourni en option.
Veuillez vous réferer à la RFC 3925 pour plus de détail.
.TP
.B \-J, --dhcp-ignore=<identifiant de réseau>[,<identifiant de réseau>]
Lorsque tous les identifiants de réseau fournis coïncident avec la liste
d'identifiants réseau dérivée des classes de réseau, hôte, vendeur et
utilisateur, ignorer l'hôte et ne pas donner de bail DHCP.
.B --tag-if=set:<label>[,set:<label>[,tag:<label>[,tag:<label>]]]
Effectue une opération booléenne sur les labels. Si tous les labels
apparaissant dans la liste tag:<label> sont positionnés, alors tous les
la de la liste "set:<labels>" sont positionnés (ou supprimés, dans le cas
où "tag:!<label>" utilisé).
Si aucun tag:<label> n'est spécifié, alors tous les labels fournis par
set:<label> sont positionnés.
N'importe quel nombre de set: ou tag: peuvent être fournis, et l'ordre est sans
importance.
Les lignes tag-if sont executées dans l'ordre, ce qui fait que si un label dans
tag:<label> est un label positionné par une rêgle
.B tag-if,
la ligne qui positionne le label doit précéder celle qui le teste.
.TP
.B --dhcp-ignore-names[=<identifiant de réseau>[,<identifiant de réseau>]]
Lorsque tous les identifiant de réseau coïncident avec la liste d'identifiants
réseau dérivées des classes de réseau, hôte, vendeur et utilisateur, ignorer le
.B \-J, --dhcp-ignore=tag:<label>[,tag:<label>]
Lorsque tous les labels fournis dans l'option sont présents, ignorer l'hôte et
ne pas donner de bail DHCP.
.TP
.B --dhcp-ignore-names[=tag:<label>[,tag:<label>]]
Lorsque tous les labels fournis dans l'option sont présents, ignorer le
nom de machine fourni par l'hôte. Il est à noter que, à la différence de
l'option "dhcp-ignore", il est permis de ne pas fournir d'identifiant réseau.
l'option "dhcp-ignore", il est permis de ne pas fournir de label.
Dans ce cas, les noms d'hôtes fournis par les clients DHCP seront toujours
ignorés, et les noms d'hôtes seront ajoutés au DNS en utilisant uniquement la
configuration dhcp-host de Dnsmasq, ainsi que le contenu des fichiers /etc/hosts
et /etc/ethers.
.TP
.B --dhcp-broadcast=<identifiant de réseau>[,<identifiant de réseau>]
Lorsque tous les identifiants de réseaux fournis correspondent à ceux
obtenus à partir des classes de réseau, d'hôte ou d'utilisateur, force
l'utilisation du broadcast pour communiquer avec l'hôte lorsque celui-ci n'est
pas configuré. La plupart des clients DHCP nécessitant une réponse par le biais
.B --dhcp-generate-names=tag:<label>[,tag:<label>]
Générer un nom pour les clients DHCP qui autrement n'en aurait pas, en
utilisant l'adresse MAC sous sa forme hexadécimale, séparée par des tirets.
Noter que si un hôte fourni un nom, celui-ci sera utilisé de préférence au nom
autogénéré, à moins que
.B --dhcp-ignore-names
ne soit positionné.
.TP
.B --dhcp-broadcast=[tag:<label>[,tag:<label>]]
Lorsque tous les labels fournis dans l'option sont présents, toujours utiliser
le broadcast pour communiquer avec l'hôte lorsque celui-ci n'est
pas configuré. Il est possible de ne spécifier aucun label, auquel cas cette
option s'applique inconditionnellement. La plupart des clients DHCP nécessitant une réponse par le biais
d'un broadcast activent une option dans leur requête, ce qui fait que cela
se fait automatiquement, mais ce n'est pas la cas de certains vieux clients BOOTP.
.TP
.B \-M, --dhcp-boot=[net:<identifiant de réseau>,]<nom de fichier>,[<nom de serveur>[,<adresse de serveur>]]
.B \-M, --dhcp-boot=[tag:<label>,]<nom de fichier>,[<nom de serveur>[,<adresse de serveur>]]
Spécifie les options BOOTP devant être retournées par le serveur DHCP. Le nom de
serveur ainsi que l'adresse sont optionnels : s'ils ne sont pas fournis, le nom
est laissé vide et l'adresse fournie est celle de la machine sur laquelle
@@ -854,11 +945,10 @@ s'exécute Dnsmasq. Si Dnsmasq founit un service TFTP (voir
.B --enable-tftp
), alors seul un nom de fichier est requis ici pour permettre un démarrage par
le réseau.
Si d'éventuels identifiants de réseau sont fournis, ils doivent coïncider avec
ceux du client pour que cet élement de configuration lui soit envoyé. Il est à
noter que les identifiants de réseau doivent-être préfixés par "net:".
Si d'éventuels labels sont fournis, ils doivent coïncider avec
ceux du client pour que cet élement de configuration lui soit envoyé.
.TP
.B --pxe-service=[net:<identifiant de réseau>,]<CSA>,<entrée de menu>[,<nom de fichier>|<type de service de démarrage>][,<adresse de serveur>]
.B --pxe-service=[tag:<label>,]<CSA>,<entrée de menu>[,<nom de fichier>|<type de service de démarrage>][,<adresse de serveur>]
La plupart des ROMS de démarrage PXE ne permettent au système PXE que la simple
obtention d'une adresse IP, le téléchargement du fichier spécifié dans
.B dhcp-boot
@@ -888,7 +978,7 @@ démarrage n'est fournie (ou qu'une valeur de 0 est donnée pour le type de
service), alors l'entrée de menu provoque l'interruption du démarrage par
le réseau et la poursuite du démarrage sur un média local.
.TP
.B --pxe-prompt=[net:<identifiant de réseau>,]<invite>[,<délai>]
.B --pxe-prompt=[tag:<label>,]<invite>[,<délai>]
Cette option permet d'afficher une invite à la suite du démarrage PXE. Si un
délai est fourni, alors la première entrée du menu de démarrage sera
automatiquement exécutée après ce délai. Si le délai vaut 0, alors la première
@@ -913,7 +1003,7 @@ dans
.B dhcp-range.
.TP
.B \-X, --dhcp-lease-max=<nombre>
Limite Dnsmasq à un maximum de <nombre> baux DHCP. Le défaut est de 150. Cette
Limite Dnsmasq à un maximum de <nombre> baux DHCP. Le défaut est de 1000. Cette
limite permet d'éviter des attaques de déni de service ("DoS") par des hôtes
créant des milliers de baux et utilisant beaucoup de mémoire dans le processus
Dnsmasq.
@@ -954,7 +1044,7 @@ utiliser avec précaution.
.TP
.B --log-dhcp
Traces additionnelles pour le service DHCP : enregistre toutes les options
envoyées aux clients DHCP et les identifiants de réseaux utilisés pour la
envoyées aux clients DHCP et les labels utilisés pour la
détermination de celles-ci.
.TP
.B \-l, --dhcp-leasefile=<chemin de fichier>
@@ -963,7 +1053,9 @@ baux DHCP.
.TP
.B \-6 --dhcp-script=<chemin de fichier>
Lorsqu'un bail DHCP est créé, ou qu'un ancien est supprimé, le fichier dont le
chemin est spécifié est exécuté. Les arguments fournis à celui-ci sont soit
chemin est spécifié est exécuté. Le <chemin de fichier> doit être un chemin
absolu, aucune recherche n'est effectuée via la variable d'environnement PATH.
Les arguments fournis à celui-ci sont soit
"add" ("ajouter"), "old" ("ancien") ou "del" ("supprimer"), suivi de l'adresse
MAC de l'hôte puis l'adresse IP et le nom d'hôte si celui-ci est
connu."add" signifie qu'un bail a été créé, "del" signifie qu'il a été supprimé,
@@ -975,43 +1067,59 @@ nécessaire de la préceder du type de réseau, par exemple "06-01:23:45:67:89:a
pour du token ring. Le processus est exécuté en temps que super-utilisateur
(si Dnsmasq a été lancé en temps que "root"), même si Dnsmasq est configuré
pour changer son UID pour celle d'un utilisateur non-privilégié.
L'environnement est hérité de celui de l'invocation du processus Dnsmasq, et
si l'hôte fournit un identifiant de client, celui-ci est stocké dans la
variable d'environnement DNSMASQ_CLIENT_ID. Si un nom de domaine pleinement
qualifié (FQDN) est connu pour l'hôte, la part relative au domaine est stockée
dans DNSMASQ_DOMAIN. Si le client fournit une information de classe de vendeur,
de classe d'utilisateur ou un nom d'hôte, celles-ci sont positionnées dans les
L'environnement est hérité de celui de l'invocation du processus Dnsmasq,
auquel se rajoute quelques unes ou toutes les variables décrites ci-dessous :
DNSMASQ_CLIENT_ID, si l'hôte a fourni un identifiant de client.
DNSMASQ_DOMAIN si le nom de domaine pleinement qualifié de l'hôte est connu, la
part relative au domaine y est stockée.
Si le client fournit une information de classe de vendeur, un nom d'hôte, ou
des classes d'utilisateur, celles-ci sont fournies dans les
variables DNSMASQ_VENDOR_CLASS et DNSMASQ_USER_CLASS0 à DNSMASQ_USER_CLASSn
et DNSMASQ_SUPPLIED_HOSTNAME respectivement, mais seulement pour les actions
"add" et "old" lorsqu'un hôte reprend un bail existant, ces variables n'étant
pas stockées dans la base de baux de Dnsmasq. Si Dnsmasq a été compilé avec
l'option HAVE_BROKEN_RTC ("horloge RTC défectueuse"), alors la durée du bail
(en secondes) est stockée dans la variable DNSMASQ_LEASE_LENGTH, sinon la date
d'expiration du bail est toujours stocké dans la variable d'environnement
DNSMASQ_LEASE_EXPIRES. Le nombre de secondes avant expiration est toujours
stocké dans DNSMASQ_TIME_REMAINING. Si un bail était associé à un nom d'hôte et
pas stockées dans la base de baux de Dnsmasq.
Si Dnsmasq a été compilé avec l'option HAVE_BROKEN_RTC ("horloge RTC
défectueuse"), alors la durée du bail (en secondes) est stockée dans la
variable DNSMASQ_LEASE_LENGTH, sinon la date d'expiration du bail est toujours
stocké dans la variable d'environnement DNSMASQ_LEASE_EXPIRES. Le nombre de
secondes avant expiration est toujours stocké dans DNSMASQ_TIME_REMAINING.
Si un bail était associé à un nom d'hôte et
que celui-ci est supprimé, un évênement de type "old" est généré avec le
nouveau statut du bail, c-à-d sans nom d'hôte, et le nom initial est fourni
dans la variable d'environnement DNSMASQ_OLD_HOSTNAME. La variable
DNSMASQ_INTERFACE contient le nom de l'interface sur laquelle la requête est
arrivée; ceci n'est pas renseigné dans le cas des actions "old" ayant lieu
après un redémarrage de dnsmasq. La variable DNSMASQ_RELAY_ADDRESS est
renseignée si le client a utilisé un relai DHCP pour contacter Dnsmasq, si
l'adresse IP du relai est connue. DNSMASQ_TAGS contient tous les labels
d'identifiants de réseau fournis pendant la transaction DHCP, séparés par des
espaces.
dans la variable d'environnement DNSMASQ_OLD_HOSTNAME.
La variable DNSMASQ_INTERFACE contient le nom de l'interface sur laquelle la
requête est arrivée; ceci n'est pas renseigné dans le cas des actions "old"
ayant lieu après un redémarrage de dnsmasq.
La variable DNSMASQ_RELAY_ADDRESS est renseignée si le client a utilisé un
relai DHCP pour contacter Dnsmasq, si l'adresse IP du relai est connue.
DNSMASQ_TAGS contient tous les labels fournis pendant la transaction DHCP,
séparés par des espaces.
Tous les descripteurs de fichiers sont fermés, sauf stdin, stdout et stderr qui
sont ouverts sur /dev/null (sauf en mode déverminage).
Le script n'est pas lancé de manière concurrente : si un autre changement de
bail intervient, le script ne sera relancé que lorsque l'exécution actuelle sera
terminée.
Le script n'est pas lancé de manière concurrente : au plus une instance du
script est executée à la fois (dnsmasq attends qu'une instance de script se
termine avant de lancer la suivante). Les changements dans la base des baux
nécessitant le lancement du script sont placé en attente dans une queue jusqu'à
terminaison d'une instance du script en cours. Si cette mise en queue fait que
plusieurs changements d'états apparaissent pour un bail donné avant que le
script puisse être lancé, alors les états les plus anciens sont supprimés et
lorsque le script sera finalement lancé, ce sera avec l'état courant du bail.
Au démarrage de Dnsmasq, le script sera invoqué pour chacun des baux existants
dans le fichier des baux. Le script sera lancé avec l'action "del" pour les baux
expirés, et "old" pour les autres. <chemin de fichier> doit être un chemin
absolu (c'est-à-dire partant de la racine "/"), aucune recherche n'aura lieu
dans les répertoires de la variable d'environnement PATH. Lorsque Dnsmasq reçoit
un signal HUP, le script sera invoqué avec une action "old" pour tous les baux
existants.
dans le fichier des baux. Le script sera lancé avec l'action "del" pour les
baux expirés, et "old" pour les autres. Lorsque Dnsmasq reçoit un signal HUP,
le script sera invoqué avec une action "old" pour tous les baux existants.
.TP
.B --dhcp-scriptuser
Spécifie l'utilisateur sous lequel le script lease-change doit être exécuté. La
@@ -1089,18 +1197,21 @@ sans gamme d'adresses de spécifié lorsque l'option
.B --dhcp-fqdn
est configurée.
.TP
.B --enable-tftp
.B --enable-tftp[=<interface>]
Active la fonction serveur TFTP. Celui-ci est de manière délibérée limité aux
fonctions nécessaires au démarrage par le réseau ("net-boot") d'un client. Seul
un accès en lecture est possible; les extensions tsize et blksize sont supportées
(tsize est seulement supporté en mode octet).
(tsize est seulement supporté en mode octet). Voir dans la section NOTES les
informations relatives à la spécification de l'interface.
.TP
.B --tftp-root=<répertoire>
.B --tftp-root=<répertoire>[,<interface>]
Les fichiers à fournir dans les transferts TFTP seront cherchés en prenant le
répertoire fourni comme racine. Lorsque cela est fourni, les chemins TFTP
incluant ".." sont rejetés, afin d'éviter que les clients ne puissent sortir de
la racine spécifiée. Les chemins absolus (commençant par "/") sont autorisés,
mais ils doivent être à la racine TFTP fournie.
mais ils doivent être à la racine TFTP fournie. Si l'option interface est
spécifiée, le répertoire n'est utilisé que pour les requêtes TFTP reçues sur
cette interface.
.TP
.B --tftp-unique-root
Ajouter l'adresse IP du client TFTP en temps qu'élément de chemin, à la suite
@@ -1322,38 +1433,48 @@ exception à ceci : si le DNS amont contient un CNAME qui pointe vers un nom
présent dans /etc/hosts, alors la recherche du CNAME via Dnsmasq fournira
l'adresse DNS amont. Pour contourner cela, il suffit de mettre l'entrée
correspondant au CNAME dans /etc/hosts.
.PP
les identifiants de réseau fonctionnent comme suit : Dnsmasq associe à chaque
requête DHCP un ensemble d'identifiants de réseau; un pour la plage d'adresse
DHCP (
le système de label fonctionne comme suit : pour chaque requête DHCP, dnsmasq
associe un ensemble de labels obtenus à partir des lignes de la configuration
incluant set:<label>, y compris un pour la plage d'adresse (
.B dhcp-range
) utilisée pour allouer l'adresse, un identifiant pour chaque entrée
) utilisée pour allouer l'adresse, un pour chaque entrée
.B dhcp-host
associée (il ajoute "known" lorsqu'une entrée dhcp-host coïncide), l'étiquette
"bootp" pour les requêtes BOOTP, un identifiant dont le nom est le nom de
l'interface sur laquelle la requête est arrivée, et éventuellement un
identifiant pour chaque classe de vendeur ou d'utilisateur
fournie par le client DHCP dans sa requête. Les options DHCP (
associée (auquel est rajouté le mot-clef "known" si une entrée dhcp-host
coïncide).
Le label "bootp" est associé aux requêtes BOOTP, un label dont le nom est le
nom de l'interface sur laquelle la requête est arrivée.
Pour les lignes de configuration comportant des éléments tag:<label>,
seules seront valides celles pour lesquels tous les labels correspondants
seront présents. C'est typiquement le cas des lignes dhcp-options.
Un
.B dhcp-option
) ayant un identifiant de réseau seront utilisés de préférence à celles
sans identifiants de réseau, pour peu que
.I tous
les labels correspondent.
Le préfixe '#' sur un label est un indicateur de négation, ainsi
.B --dhcp=option=#purple,3,1.2.3.4
envoie l'option lorsque le label "purple" n'est pas dans la liste de labels
valides pour l'hôte considéré.
possédant des labels sera utilisé de préférence à un
.B dhcp-option
sans label, pour peu que _tous_ les labels positionnés correspondent à l'ensemble
de labels décrit plus haut.
Le préfixe '!' sur un label est un indicateur de négation, ainsi
.B --dhcp=option=tag:!purple,3,1.2.3.4
n'envoie l'option que lorsque le label "purple" n'est pas dans la liste de
labels définis pour l'hôte considéré. (dans le cas de l'utilisation dans une
ligne de commande au lieu d'un fichier de configuration, ne pas oublier
d'échapper le caractère !, qui est un méta-caractère d'interpréteur de commande
shell).
.PP
Si l'identifiant de réseau dans la plage d'adresses DHCP (
.B dhcp-range
) est préfixé par 'net:', alors sa signification change : au lieu d'associer un
label à la plage spécifiée, cela indique un label de réseau devant être spécifié
par le client DHCP. Ainsi, s'il y a plus d'une plage d'adresses DHCP sur un
sous-réseau, et que l'une est préfixée par un identifiant de réseau (par exemple
l'un spécifié dans une option de classe de vendeur), alors un hôte ayant
l'identifiant de réseau en question positionné se verra allouer une adresse dans
la plage d'adresses DHCP préfixée.
Veuillez noter que pour
.B dhcp-range
, les éléments tag:<label> et set:<label> sont tous les deux autorisés
pour sélectionner la plage à utiliser selon, par exemple, le dhcp-host,
et pour affecter l'option envoyée, sur la base de la plage sélectionnée.
Ce système a évolué d'un système plus ancien et aux possibilités plus limitées,
et pour des raisons de compatibilité "net:" peut être utilisé à la place de
"tag:" et "set:" peut-être omis (à l'exception de
.B dhcp-host,
où "net:" peut-être utilisé à la place de "set:"). Pour les mêmes raisons, '#'
peut-être utilisé à la place de '!' pour indiquer la négation.
.PP
Le serveur DHCP intégré dans Dnsmasq fonctionne également en temps que serveur
BOOTP, pour peu que l'adresse MAC et l'adresse IP des clients soient fournies,
@@ -1366,12 +1487,55 @@ ou dans le fichier
soit présente afin d'activer le serveur DHCP pour un réseau donné (L'option
.B --bootp-dynamic
supprime la nécessité des associations statiques). Le paramètre
"filename" (nom de fichier) de la requête BOOTP est comparé avec les
identifiants de réseaux des options
.B dhcp-option
ainsi que le label "bootp", ce qui permet de contrôler les options retournées
"filename" (nom de fichier) de la requête BOOTP est utilisé comme label, ainsi
que le label "bootp", permettant un certain contrôle sur les options retournées
aux différentes classes d'hôtes.
Il est possible de spécifier un nom d'interface à
.B dhcp-range
sous la forme "interface:<nom d'interface>". La sémantique est comme suit :
Pour le DHCP, s'il existe une autre valeur de dhcp-range pour laquelle
_aucun_ nom d'interface n'est donné, alors le nom d'interface est ignoré
et dnsmasq se comporte comme si la partie spécifiant l'interface n'existait
pas, sinon le service DHCP n'est fourni qu'aux interfaces mentionnées dans
les déclarations dhcp-range. Pour le DNS, si il n'y a pas d'option
.B --interface
ou
.B --listen-address
, alors le comportement n'est pas impacté par la spécification d'interface. Si
l'une ou l'autre de ces options est présente, alors les interfaces mentionnées
dans les plages d'adresses dhcp-range sont rajoutées à la liste de celles
où le service DNS est assuré.
De manière similaire,
.B enable-tftp
peut prendre un nom d'interface, ce qui active le TFTP pour cette seule
interface, en ignorant les options
.B --interface
ou
.B --listen-address
De plus,
.B --tftp-secure
,
.B --tftp-unique-root
et
.B --tftp-no-blocksize
sont ignorées pour les requêtes sur de telles interfaces. (une directive
.B --tftp-root
donnant le chemin de la racine et une interface doit-être fournie).
Ces règles peuvent paraître étrange à première vue, mais elles permettent
d'ajouter à la configuration de dnsmasq des lignes de configuration de la
forme "dhcp-range=interface:virt0,192.168.0.4,192.168.0.200" afin de fournir
un service DHCP et DNS sur cette interface, sans pour autant affecter les
services fournis sur d'autres interfaces, malgré l'absence de paramètres
"interface=<interface>" sur les autres lignes de configuration.
"enable-tftp=virt0" et "tftp-root=<root>,virt0" effectuent la même chose pour
TFTP.
L'idée de tout cela est de permettre l'addition de telles lignes
automatiquement par libvirt ou un système équivalent, sans perturbation
d'une configuration manuelle existant par ailleurs.
.SH CODES DE SORTIE
.PP
0 - Dnsmasq s'est correctement lancé en tâche de fond, ou alors s'est
@@ -1403,10 +1567,8 @@ ultérieur : les versions précédentes ne montaient pas en charge aussi bien.
.PP
Dnsmasq est capable de gérer le DNS et DHCP pour au moins un millier de clients.
Evidement, pour cela la valeur de
.B --dhcp-lease-max
doit être augmentée et la durée des baux ne doit pas être très courte (moins
d'une heure). La valeur de
Pour cela, la durée des bail ne doit pas être très courte (moins d'une heure).
La valeur de
.B --dns-forward-max
peut-être augmentée : commencer par la rendre égale au nombre de clients et
l'augmenter si le DNS semble lent. Noter que la performance du DNS dépends